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I. 


INTRODUCTION 


On  March  21,  2003,  during  the  first  days  of  Operation 
Iraqi  Freedom  (OIF) ,  as  a  member  of  the  15th  Marine 
Expeditionary  Unit  (MEU)  ,  this  researcher'’  s  position  was 
attacked  by  Iraqi  paramilitary  forces.  The  attack  was 
against  the  MEU' s  forward  command  post  (CP)  established  at 
the  Iraqi  naval  port  in  the  southern  Iraqi  city  of  Umm  Qasr. 
The  attack  came  as  the  MEU' s  ground  combat  power,  the 
Battalion  Landing  Team  (BLT) ,  attacked  north  to  secure  their 
next  objective.  This  BLT  attack  left  the  MEU  command  post  at 
its  most  vulnerable— and  the  enemy  paramilitary  forces  seized 
the  opportunity. 

This  Iraqi  counter-attack  was  repelled  by  one  BLT  rifle 
company  that  had  been  left  to  secure  the  MEU  CP  and  protect 
the  Marines,  soldiers,  sailors  of  the  CP.  The  attackers 
subsequently  consolidated  into  a  relatively  isolated  group 
of  buildings  previously  cleared  by  the  BLT  rifle  company.  In 
the  midst  of  the  attack,  the  MEU  commander  authorized  the 
use  of  the  BLT's  artillery  battery  to  defend  the  MEU  CP.  The 
target  requests  were  transmitted  to  the  artillery  battery  by 
both  the  MEU  staff  officers  and  the  BLT  rifle  company's 
Artillery  Forward  Observer  via  the  traditional  fire  support 
communication  network  (i.e.,  both  voice  and  data 
communication  on  Very  High  Frequency  (VHF)  radios,  one  each, 
voice  communications  on  both  Ultra  High  Frequency  (UHF)  and 
High  Frequency  (HF) ) .  These  requests  went  unanswered  by  the 
artillery  battery.  The  situation  dictated  that  every 
available  means  be  used  to  communicate  enemy  targets  to  the 
artillery  battery  in  defense  of  the  MEU  CP. 
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This  researcher,  as  a  trained  Forward  Observer,  called 
the  artillery  battery  using  the  Kuwaiti  cellular  phone 
issued  for  inter-camp  coordination  prior  to  the  start  of 
OIF.  The  artillery  battery  answered  the  cellular  phone  call 
and  shifted  to  support  the  defense  of  the  MEU  CP.  As  a 
result,  the  Iraqi  paramilitary  force  concentrations  were 
repelled  and  the  MEU  CP  remained  secured. 

This  combat  experience  posed  a  question:  "Why  can  the 
most  technologically  advanced  country  on  earth  not  develop  a 
communications  device  that  simplifies  the  users''  actions  by 
consolidating  the  capabilities  of  the  several  required 
communications  devices  into  one  'smart'  device."  In  combat, 
the  warfighter  should  ideally  carry  one  smart  device  that 
can  communicate  on  all  required  networks  and  formats,  both 
voice  and  data,  to  achieve  maximum  effectiveness  while 
minimizing  equipment. 

A.  PROBLEM  AND  MOTIVATION 

As  America's  Force-in-Readiness,  the  Marine  Corps  must 
remain  a  rapidly-deployable,  lightweight  force  capable  of 
successfully  operating  in  a  variety  of  contingencies,  from 
humanitarian  operations  to  conventional  warfare.  The  Marine 
Corps  conducts  its  operations  using  the  Marine  Air  Ground 
Task  Force  (MAGTF)  concept. 

The  goal  of  the  MAGTF  is  Air-Ground  coordination  to 
maximize  the  effects  of  the  available  forces.  In 
conventional  combat  operations,  this  is  known  as  the 
application  of  combined  arms.  At  the  heart  of  the  combined 
arms  concept  is  the  requirement  for  the  Ground  Combat 
Element  (GCE)  to  synchronize  and  coordinate  the  available 
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fire  support  assets  of  the  MAGTF  (MCDP  1.0,  2001) .  The  fire 
support  coordination  aspect  of  Command  and  Control  (C2)  is 
an  immensely  complex  operation  that  relies  heavily  on  both 
the  communication  and  coordination  skills  of  the  fire- 
support  Marines  at  the  tactical  level. 

These  tactical  level  warfighters  are  overburdened  by 
multiple  incomplete  functional  devices  that  provide  single- 
frequency-spectrum-capable  communications  without  providing 
any  other  warfighting  functionality,1  i.e.,  coordinate 
fires,  track  enemy  locations,  or  show  friendly  maneuver  in 
the  vicinity.  Instead,  there  is  another  device  that  must  be 
used  to  display  or  interact  with  the  information,  and  that 
additional  device  must  be  tethered  to  a  communications 
device  to  retain  relevant  information. 

These  additional  devices  actually  increase  logistical 
requirements  and  decrease  combat  capabilities  by  limiting 
mobility.  However,  by  reducing  the  communication  and 
logistics  requirement  of  the  warfighters,  an  organization 
may  allow  the  company  and  the  battalion  greater  flexibility 
and  mobility.  If  a  single  military  communication  device, 
modeled  after  a  commercial  smartphone,  were  adapted  to 
provide  combat  utility  with  warfighting  functional 
applications,  the  device  could  make  the  user  more  responsive 
and  lethal  in  combat. 

Therefore,  this  thesis  intends  to  explore  a  smartphone 
application  that  could  be  used  on  a  commercially  available 
device  that  would  enable  the  warfighter  the  most  effective 
use  of  all  available  communication  networks  to  conduct  fire 

1  MCDP  1-0  defines  the  six  warfighting  functions  as:  command  and 
control,  intelligence,  maneuver,  fires,  logistics  and  force  protection. 
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support.  This  single  device  would  be  able  to  transmit  and 
receive  information  over  a  variety  of  available  networks, 
including  tactical  cellular,  and  could  use  any  required 
network  in  order  to  accomplish  the  warfighter' s  needs  at  the 
tactical  level.  This  thesis  will  only  consider  the  use  of 
the  application  at  the  tactical  level,  defined  as  the 
Infantry  Battalion  and  below  (e.g..  Company  through  Fire 
Team) .  The  secondary  guestion  is  then  explored:  "How  can  the 
USMC  develop  such  applications  to  benefit  wartime 
communications?" 

B.  OBJECTIVES 

The  USMC  could  benefit  from  improved  wartime 
communications  via  the  exploration  of  commercial  off-the- 
shelf  (COTS)  software,  hardware,  and  the  existing  network 
infrastructure  to  begin  the  development  of  smartphone 
applications.  This  thesis  seeks  to  resolve  a  gap  in 
capabilities  by  providing  a  prototype  fire  support 
application  that  serves  as  a  proof-of-concept  for  rapidly 
developed  applications  that  have  an  immediate  positive 
impact  through  enhanced  warfighter  capabilities.  This  thesis 
will  focus  on  USMC  fire  support  networks,  although  the 
lessons  learned  will  be  applicable  across  the  joint 
services.  A  wireless  backbone  for  integration  with  current 
fire  support  C2  systems,  specifically  the  Advanced  Field 
Artillery  Tactical  Data  System  (AFATDS) ,  will  be  used  as  the 


4 


point  of  departure.  This  will  involve  the  prototyping  of  a 
smartphone  application  to  request  and  deconflict2  fire 
support  at  the  tactical  level. 

Current  Naval  network  research  direction,  as  indicated 
by  Naval  Research  Laboratory  (NRL)  Broad  Agency  Announcement 
(BAA)  55-09-07,  seeks  the  exploration  of  commercial  standard 
wireless  networks,  such  as  IEEE  802.11  and  IEEE  802.16 
standards,  as  extensions  to  the  tactical  edge  network  (Naval 
Research  Laboratory,  2007).  This  prototype  cannot  succeed 
without  progress  in  the  adoption  of  all  wireless 
communication  methods  to  extend  the  tactical  edge  of  the 
fire  support  network.  This  thesis  will  further  pursue  the 
exploration  of  any  communications  paths  currently  provided 
via  commercial  smartphones  such  as  IEEE  802.11  and  IEEE 
802.16  resident  on  most  devices. 

More  recent  is  the  Defense  Advanced  Research  Projects 
Agency  (DARPA)  research  direction  published  as  BAA  10-41 
(DARPA,  2010) .  The  BAA  titled  Transformative  Apps,  called 
for  "innovative  research  in  the  area  of  tactical  application 
development,  evaluation  and  enhancements...to  place  the  right 
mobile  software  applications  ("apps")  into  the  hands  of  the 
warfighter  as  the  apps  are  needed"  (DARPA,  2010)  .  The 
announcement  goes  on  to  discuss  the  creation  of  an  Apps 
Marketplace  Architecture  and  the  estimated  further  research 
areas  the  BAA  will  spawn.  The  NRL  and  DARPA  BAAs  provided  a 
strong  foundation  for  this  researcher  to  attempt  to  resolve 


2  In  MCWP  3-16,  deconf liction  is  defined  as  the  process  of  ensuring 
fire  support  agencies'  targets,  timelines  and  battlefield  geometries  are 
able  to  achieve  the  optimum  effects  in  support  of  the  ground  commander' s 
scheme  of  maneuver  without  incurring  unnecessary  risk  to  friendly 
personnel  or  equipment. 
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a  capabilities  gap  in  Marine  Corps  fire  support  by  using  a 
smartphone  to  get  fires  down  to  the  tactical  edge. 

The  Marine  Corps  fire  support  network  needs  to  take  the 
next  logical  step  of  adopting  all  relevant,  existing,  and 
foreseeable  future  networking  technologies  to  fill  any  gaps 
for  an  enhanced  network  using  redundant  network  nodes  for 
fire  support  C2 .  The  emergence  of  chat  and  chat-based 
services  to  provide  notifications  of  changes  in  friendly 
locations,  fire  support  plans,  or  fire  support  coordination 
measures,  has  emerged  throughout  the  current  operating 
environment.  The  chat-based  services  became  a  de  facto 
standard  network  requirement  for  fire  support  deconf liction 
in  the  Joint  and  Combined3  operating  environments  of  both 
Operation  Enduring  Freedom  (OEF)  and  Operation  Iraqi  Freedom 
(OIF)  (Eovito,  2006) .  These  chat-based  services  are  now 
equally  important  to  the  tactical  level  warfighter  from  the 
company  level  to  the  individual  Marine,  as  evidenced  in  the 
Capability  Set  5  Urgent  Needs  Statement  (Hastings,  2009) . 
This  evidence  provides  the  impetus  for  immediate  exploration 
of  smartphone  devices  to  provide  these  types  of  services  for 
the  warfighter. 

C .  RESEARCH  QUESTIONS 

This  thesis  will  be  guided  by  the  following  questions: 

•  How  can  COTS  software  developmental  tools  be  used 
to  produce  a  smartphone  application  to  aid  the 
transition  between  traditional  radio  equipment  and 
a  tactical  cellular  network? 


3  Joint  operations  refer  to  operations  where  two  or  more  military 
departments  operate;  combined  operations  involve  two  or  more  allied 
nations  or  agencies  (JP  1-02,  2011)  . 
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•  How  does  the  SMART  Fires  application  fit  into 
existing  and  future  Command  and  Control  platforms 
in  integrating  information  into  a  Common  Tactical 
Picture  (CTP)  that  will  assist  the  warfighter? 

•  How  effective  will  these  COTS  applications  be  in 
aiding  the  warfighter  (e.g.,  target  location 
precision,  request  latency,  situational  awareness 
increases,  and  efficiency)  ? 

D.  SCOPE  AND  LIMITATIONS 

The  thesis  will  not  attempt  to  design  the  "best"  fire 
support  application,  thereby  requiring  a  rewrite  of  doctrine 
to  include  tactical  cellular  or  WiFi  or  even  WiMax  networks 
as  required.  Neither  will  this  research  attempt  to  include 
communications  security  concerns  or  network  security 
concerns  that  would  exist  for  integration  into  the  current 
system.  This  research,  however,  seeks  to  demonstrate  a  proof 
-of-concept  to  verify  that  the  fire  support  application. 
Smartphone  to  AFATDS  Prototype  (SMART)  Fires,  is  feasible. 
If  feasible,  then  the  SMART  Fires  application  would  be 
capable  of  leveraging  a  future  cellular  wireless  technology 
for  the  military. 

The  Marine  Corps'  fire  support  infrastructure  was 
chosen  because  of  the  readily  available  resources,  including 
the  author's  background  as  a  Marine  Artillery  Officer; 
however,  the  results  of  the  research  are  applicable  across 
all  six  warfighting  functions.  After  further  refinement  of 
the  technology,  we  believe  the  SMART  Fires  application  can 
provide  the  basis  for  further  application  development  in 
support  of  a  platform  hardened  to  Military  Standards 
(MILSTD) ,  capable  of  all  wireless  communication  requirements 
for  any  tactical  traffic.  We  envision  that  these  efforts 
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will  springboard  other  warfighting  communities  to  design  and 
implement  similar  supporting  applications  to  enable  those 
Marines  to  better  perform  their  function  in  combat.  By 
furthering  the  study  of  COTS  Software  Development  Kits 
(SDKs)  to  harness  these  existing  commercial  technologies  in 
a  form  that  remains  rapidly  developable  by  the  warfighter, 
our  research  intends  to  reduce  the  logistics  required  for 
Marines  to  remain  America' s  force-in-readiness  and  to 
continue  to  win  America's  battles. 

This  thesis  seeks  to  validate  a  proof-of-concept 
whereby  cellular  technology  can  provide  a  fire  support 
network  that  is  flexible  and  capable  of  rapid  integration 
using  existing  wireless  infrastructure  in  any  theater  of 
operation,  and  then  transition  back  and  forth  to  tactical 
radio  nets  as  reguired.  The  research,  though  conducted  in 
the  narrow  scope  of  Marine-specific  fire  support  operations 
at  the  tactical  level,  can  be  transitioned  across  the 
Department  of  Defense  (DoD) . 

E.  THESIS  ORGANIZATION 

This  first  chapter  provides  an  overview  of  known 
discrepancies  within  the  Marine  Corps'  fire  support  network 
infrastructure.  The  chapter  goes  on  to  suggest  objectives 
that  can  be  achieved  through  the  successful  integration  of 
the  SMART  Fires  application  as  a  part  of  the  overall 
adoption  of  smartphone  integration  into  military  wireless 
communications.  Finally,  the  chapter  outlines  the  research 
questions  that  were  evaluated  and  will  guide  the  remainder 
of  this  research. 


8 


Chapter  II  discusses  the  current  state  of  the  USMC  fire 
support  networks  and  the  current  fire  support 
software/hardware  platforms.  It  outlines  the  coordination 
requirements  for  a  USMC  tactical  fire  support  network, 
including  the  required  communication  nodes  and  C2  actions  to 
successfully  conduct  fire  support. 

Chapter  III  provides  a  background  for  previous  tactical 
cellular  network  integration.  It  outlines  the  selection  of 
the  operating  system  for  development  of  the  application 
prototype  and  provides  a  description  of  the  Android™ 
environment.  It  provides  user  requirements  and  an  evaluation 
of  support  by  the  fully  developed  application  Finally,  the 
chapter  finishes  with  a  description  of  the  Eclipse™ 
integrated  development  environment  and  the  Commonsware (LLC) 
references  used  in  the  development  of  the  SMART  Fires 
application . 

Chapter  IV  presents  the  SMART  Fires  prototype 
requirements  and  design 

The  results  and  final  conclusions  of  the  proof-of- 
concept  are  given  in  Chapter  V.  The  chapter  also  sets  forth 
recommendations  for  continued  development  of  SMART  Fires  and 
the  best  way  ahead  for  SMART  applications. 
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II.  BACKGROUND 


This  chapter  provides  the  necessary  background 
regarding  previous  research  as  to  why  and  how  smartphones 
and  a  tactical  cellular  network,  integrated  with  the 
existing  military  wireless  network,  could  help  to  fill 
existing  communications  gaps  and  extend  significant  network 
capability  to  the  warfighter.  The  chapter  then  describes  the 
organization  of  the  Marine  Corps  fire  support  agencies  and 
the  composition  of  the  tactical  level  agencies.  The  chapter 
elaborates  on  current  equipment  and  systems  implemented  to 
conduct  fire  support  at  the  tactical  level.  It  further 
outlines  the  coordination  requirements  for  those  tactical 
fire  support  systems  to  successfully  request  and  deconflict 
a  "call  for  fire." 

A .  WHY  SMARTPHONES 

The  platform  for  a  smartphone  integrates  several 
current  standalone  system  capabilities  into  a  singular 
device.  These  hardware  capabilities  include:  accelerometer, 
gyroscope,  compass,  cameras  (forward  and/or  rear  facing)  for 
still  or  video.  Global  Positioning  System  (GPS) ,  cellular 
transceiver  for  voice  and/or  data,  Bluetooth™  personal  area 
network  (PAN)  interface,  WiFi  802.11  standard  Local  Area 
Network  (LAN)  interface,  in  some  cases  the  WiMAX  802.16 
standard  Metropolitan  Area  Network  (MAN)  interface,  and  the 
ability  to  communicate  over  all  of  these  wireless  networks. 
Both  Android  and  iPhone  application  markets  have 
applications  that  can  initiate  a  pairing  through  the 
accelerometer  then  use  the  802.11  standard  or  cellular  data 
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connection  to  communicate  using  a  cloud  infrastructure;  the 
BUMP™  application  is  one  such  example  (BUMP,  2011)  .  The 
current  data  rates  are  up  to  31  Mbps  per  second  for  mobile 

WiMAX  (Benes  &  Prokopec,  2011)  and  45  Mbps  for  Long  Term 

Evolution  (LTE)  (Wylie-Green  &  Svensson,  2010) ;  mobile  WiFi 
connectivity  with  802. lln,  still  achieved  data  rates  in 
excess  of  15  Mbps  (Lin,  Tzu,  Lin,  &  Lee,  2009)  ,  and  the 
hardware  chipsets  required  to  conduct  WiFi  calling  or 
Unlicensed  Mobile  Access  (UWA)  directly  or  using  Voice  over 
WiFi  (VoWiFi)  also  exist.  These  current  capabilities,  among 

others,  were  the  impetus  for  both  the  United  States  Army 

(USA)  and  the  USMC  to  explore  smartphone  technology 
integrated  into  the  tactical  network. 

The  SMART  Fires  application  is  a  prototype  that  will 

demonstrate  a  proof-of-concept  that  COTS  SDKs  can  be  used  by 

the  operating  forces  to  implement  new  ideas  into  a  rapidly 

deployable  software  application  for  smartphones.  This  type 

of  rapid  prototype  development  is  only  possible  if  the 

Marine  Corps  adopts  the  appropriate  wireless  infrastructure. 

Since  there  is  no  open  developmental  environment  for 

programs  of  record  that  currently  exist  in  the  Marine  Corps, 

Joshua  S.  Dixon's  thesis,  "Integrating  Cellular  Handset 

Capabilities  with  Marine  Corps  Tactical  Communications," 

published  in  May  of  2010,  lays  out  the  concepts  that,  if 

adopted,  could  leverage  the  high  mobility  and  unique 

computing  capability  resident  in  most  smartphones  in  the 

commercial  market  without  having  to  wait  through  the  delay 

of  the  traditional  military  acquisitions  process.  Since  the 

commercial  market  is  driven  by  the  competition  of  other 

hardware  and  service  providers  to  put  out  a  cutting  edge 

technology  product,  it  stimulates  innovation  and  furthers 
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the  requirement  for  providers  to  deliver  the  best  available 
product  at  all  times.  The  risk  associated  with  the 
commercial  market  is  principally  financial  (O'Neal  &  Dixon, 
2011)  .  A  company's  failure  to  deliver  the  most  current 
technology  allows  competitors  to  gain  market  share  and  the 
affected  company  will  lose  revenue.  The  risk  of  the 
military' s  failure  to  adopt  emergent  technology  has  much 
greater  consequences  since  it  could  mean  a  weakened  national 
defense  and  military  advantages  forfeited  to  nations  or 
nonstate  actors  that  do  adopt  the  leading  edge  of 
technology . 

Dixon  proposed  two  solutions  to  integrate  smartphones 
into  military  tactical  communications:  wired  and  wireless. 
The  wired  approach  is  referred  to  as  the  tethered  concept. 
This  concept  adopts  the  integration  technique  used  for  the 
AN/PSC-13  Dismounted-Data  Automated  Communications  Terminal 
(D-DACT)  .  The  device  can  be  used  independently  of  military 
communication  systems  or  can  be  integrated  directly  through 
a  wired  connection  to  a  SINCGARS  radio  set.  Although 
tethering  does  provide  solutions  to  security  concerns,  since 
it  uses  a  military  radio  for  integration,  the  true  benefits 
of  the  highly  mobile  smartphone  are  not  yet  fully  leveraged. 

The  wireless  approach  has  two  paths  that  provide 
avenues  to  smartphone  integration  in  tactical 
communications.  The  first  method,  indirect  bridging, 
requires  the  use  of  additional  hardware  integrated  into  the 
tactical  communications  networks.  These  networks  leverage 
mobile  base  stations  to  provide  the  required  small  scale 
capabilities  of  larger  metropolitan  cellular  base  stations 
in  the  footprint  of  a  single  tactical  vehicle.  There  are  a 
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variety  of  hardware  solutions  that  fulfill  the  needs  of  an 
indirect  bridging  solution;  however,  the  Open  Base 
Transceiver  Station  project  (OpenBTS)  offers  the  ability  to 
connect  Global  System  for  Mobile  Communications  (GSM) 
standard  smartphones  on  the  tactical  network  with  VoIP 
clients,  without  the  hardware  overhead  required  in 
commercial  cellular  networks. 

The  commercial  cellular  infrastructure  is  composed  of 
the  Base  Transceiver  Station  (BTS) ,  the  Base  Station 
Controller  (BSC) ,  and  the  Mobile  Switching  Center  (MSC) .  The 
wireless  connection  between  the  GSM-capable  cellular  device 
and  the  GSM  network  is  provided  by  the  BTS.  As  a  cellular 
device  moves  from  one  coverage  area  to  another,  the  BSC 
provides  a  portion  of  the  handover  functionality  that 
enables  the  transition.  Finally,  the  MSC  provides  the  main 
functionality  for  BTS  transition  and  the  end-to-end 
connections  that  either  begin  or  end  with  a  cellular  device 
in  its  coverage  area.  This  commercial  GSM  infrastructure  is 
shown  in  Figure  1 . 
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Figure  1.  Commercial  cellular  MSC-BSC  architecture 

(From  Dixon,  2010)  . 

In  OpenBTS,  the  Universal  Software  Radio  Peripheral 
(USRP)  uses  Asterix©  Private  Branch  Exchange  (PBX)  to 
provide  the  required  GSM  functionality  to  make  and  receive 
VoIP  calls.  OpenBTS  replaces  the  BTS,  BSC  and  the  MSC  with  a 
minimal  infrastructure  composed  of  a  hardware  device  capable 
of  running  the  open  source  software,  OpenBTS  and  Asterix© 
PBX,  and  other  software  to  enable  a  VoIP  client  on  the 
hardware  device.  A  comparison  of  Figures  1  and  2  will 
illustrate  the  reduction  in  equipment  between  a  standard 
commercial  cellular  infrastructure  and  the  minimum  OpenBTS 
infrastructure  required  to  complete  a  voice  call. 
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Figure  2.  OpenBTS  architecture  (From  Dixon,  2010)  . 

The  final  integration  method  in  Captain  Dixon' s  work  is 
Direct  Interfacing .  The  work  goes  on  to  explain  that  by  the 
military  creating  the  need  for  marginal,  military-specific 
(MIL-SPEC)  ,  adaptations  to  the  commercial  hardware, 
producers  could  create  hardware  modularity  in  handsets 
intended  for  dual  purpose  use,  commercial  and/or  military 
applications.  Secondly,  the  notion  of  software  portability 
is  introduced  to  provide  a  method  for  the  smartphone  and 
tactical  handset  modifications  to  be  made  to  the  software 
and  firmware  loaded  into  the  handsets,  both  cellular  and 
military  tactical  radios,  for  integration  into  one  another's 
networks.  The  integration  is  proposed  by  three  solutions: 
(i)  adding  a  MIL-SPEC  signal  to  smartphone,  (ii)  adding 
commercial  cellular  signal  capability  to  the  military  radio, 
or  (iii)  modifying  cellular  protocol  to  be  useable  by  both 
smartphones  and  military  radios.  Each  proposal  provides 
unique  answers  to  integration  and  new  areas  of  security 
concerns.  All  three  are  theoretically  feasible  solutions  for 
smartphone  integration  into  tactical  military  networks, 
though  not  necessarily  monetarily  viable.  Whatever  solution 
or  integration  technique  is  chosen,  the  fact  remains  that 
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this  technology  could  provide  both  computing  and  networking 
capabilities  that  would  enhance  tactical  operations  in  a 
form  with  which  the  individual  Marine  or  soldier  is  very 
familiar.  So,  with  a  familiar  platform,  the  ease  of  use  and 
navigation  of  the  new  system  is  second  nature,  allowing  the 
focus  of  the  users  to  return  to  their  warfighting  task. 

With  respect  to  the  scope  of  this  research,  that 
warfighting  task  is  requesting  fire  support  in  the  form  of  a 
Call  For  Fire  (CFF)  .  The  CFF,  however,  is  the  critical 
information  that  must  pass  through  a  detailed  and  refined 
coordination  and  deconf liction4  process  before  it  is 
reali zed— when  the  artilleryman  manning  his  weapon  system 
fires  a  projectile  at  the  target.  The  Marine  Corps-specific 
CFF  process  is  provided  for  an  understanding  of  the  current 
standing  voice  CFF  procedure.  It  is  our  belief  that  through 
an  examination  of  both  the  tactical  organizations  who 
conduct  fire  support  coordination,  combined  with  the  tasks 
required  by  the  entry  level  Marine  with  Military 
Occupational  Specialty  (MOS)  0861-Fire  Support  Man,  that  the 
proof  of  how  an  intuitive  SMART  Fires  application  will 
positively  benefit  this  fire  support  process  and  may  be 
revealed. 

B.  MARINE  CORPS  FIRE  SUPPORT 

Fire  support  coordination  is  among  the  most  complex 
processes  that  America' s  military  performs  during 
conventional  wartime  operations.  Transient  to  the  levels  of 

4In  MCWP  3.16  deconf liction  is  defined  as  the  coordination  with 
higher  and  adjacent  units  during  fire  support  planning.  Deconf liction  is 
facilitated  through  the  fire  support  coordination  measures  (FSCM)  and 
separation  of  the  gun  to  target  line  by  time  or  space  with  friendly 
units . 
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war,  fire  support  at  the  strategic  level  directly  impacts 
the  tactical  level,  and  vice  versa.  As  a  result  of  this 
transient  nature,  fire  supporters  executing  the  fire  support 
plan  must  be  able  to  coordinate  with  all  levels  of  command. 
This  communications  requirement  crosses  geographical, 
service  and  national  boundaries  to  maximize  the  effects  of 
limited  fire  support  assets,  and  to  be  most  effective,  it 
requires  the  best  technology  available.  Without  this 
communication,  our  nation  risks  squandering  assets  and,  most 
importantly,  the  lives  of  our  warfighters. 

1 .  Marine  Unit  Organization 

A  traditional  Marine  Corps  artillery  battalion  is 
composed  of  three  artillery  firing  batteries  that  provide 
fire  support  to  the  supported  maneuver  infantry  battalions 
and  a  headquarters  battery  that  provides  the  equipment  and 
staff  to  enable  command  and  control  for  the  artillery 
battalion  (MCWP  3-16.1,  2002).  The  artillery  battalion 
provides  fire  support  for  the  maneuver  infantry  regiment  in 
two  ways;  first,  through  the  organic  artillery  firing 
batteries  providing  close  and  continuous  fires  to  the 
supported  infantry  battalion,  and  second,  by  providing  the 
fire  support  personnel  and  equipment  to  conduct  fire  support 
planning  and  coordination  to  both  the  infantry  regimental 
commander  and  the  infantry  battalion  commanders.  The  unit 
organization  and  supporting  relationships  are  shown  in 
Figure  3.  The  tactical  fire  support  organizations  formed  at 
the  infantry  battalion  and  down  to  the  companies  are 
explored  further  in  this  study. 
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-Organic  Unit- 


Figure  3.  Artillery-to-maneuver  tactical  organization 

and  support  relationships. 


2 .  Marine  Fire  Support  Organizations 

Tactical  fire  support  is  executed  on  behalf  of  the 
supported  maneuver  commander;  therefore,  the  tactical  fire 
support  organizations  are  co-located  with  the  maneuver 
commander' s  Combat  Operations  Center  (COC) .  Tactical  fire 
support  organizations  exist  at  every  level  within  the 
infantry  command  structure,  from  the  division  to  the 
company.  The  infantry  battalion  level  fire  support 
organization  is  the  Fire  Support  Coordination  Center  (FSCC) . 
The  FSCC  is  a  composite  organization  made  up  of  both  the 
infantry  battalion  personnel  and  the  supporting  artillery 
battery's  liaison  section  personnel  (MCWP  3-16,  1999).  The 

next  level  of  fire  support  organization  at  the  infantry 
company  is  the  Fire  Support  Team  (FiST) .  The  FiST  is  also  a 
composite  organization,  with  members  of  both  the  infantry 
company  and  the  supporting  artillery  battery' s  Forward 
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Observer  (FO)  team.  The  artillery  battery  FO  team  is  the 
first  fire  support  organization  employed  in  support  of  the 
infantry  (FM  6-30,  1991),  to  advise  the  infantry  company 

commander  on  the  employment  of  artillery  fires  in  support  of 
the  company's  scheme-of-maneuver  (MCWP  3-16.6,  1998). 

a .  Compos i tion 

Starting  first  at  this  lowest  level,  the  FO  team 
consists  of  four  members: 

•  Forward  Observer-MOS  0802 

•  Fire  Support  Man-MOS  0861 

•  two  Radio  Operators-MOS  0621 

The  FO  Team  then  takes  its  place  as  part  of  the 
Fire  Support  Team  (FiST)  .  The  company  FiST  and  battalion 
FSCC  have  a  parallel  structure  to  facilitate  simultaneous 
coordination  and  deconf liction  between  the  FiST  and  their 
counterparts  at  the  FSCC. 

The  FiST  and  the  FSCC  contain  a  representative 
from  each  supporting  arm.  At  these  two  organizations  the 
infantry  representative  also  serves  as  the  leader  for  the 
organization  since  he  is  appointed  by  the  commander  of  the 
unit  the  fires  are  supporting.  The  FiST  composition  is: 

•  FiST  Leader  ( inf antryman) -MOS  0302 

•  FO  Team  (artillery) -MOS  0802 

•  mortarman  observer-MOS  0341 
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•  Close  Air  Support  (CAS)  representative5-MOS  7502 
or  8002 

•  Naval  Gunfire  (NGF)  spot  team 

At  the  FSCC,  each  supporting  arm  is  represented, 
providing  a  thorough  knowledge  of  the  employment  of  each 
supporting  arm  to  the  Fire  Support  Coordinator  (FSC)  .  The 
representatives  for  the  various  supporting  arms  are: 

•  FSC  ( inf antryman) -MOS  0302 

•  Artillery  Liaison  Officer  (Arty  LNO) -MOS  0802 

•  Senior  Noncommissioned  Officer  (NCO)  mortarman 
observer-MOS  0341 

•  Air  Officer  (AO) -MOS  7502 

•  Naval  Gunfire  Liaison  Officer  (NGLO) -MOS  0845 

All  representatives  are  assisted  by  more  radio 
operators  and,  for  the  artillery  and  the  NGLO,  by  an 
enlisted  advisor  that  enhances  the  experience  level  in  the 
FSCC  (MCWP  3-16.6,  1998).  The  NGLO  and  the  NGF  spot  teams 
are  collectively  known  as  the  Shore  Fire  Control  Party 
(SFCP)  (MCWP  3-16.6,  1998). 

b.  Communications 

Many  radio  assets  and  systems  are  required  to 
support  the  coordination  of  fires.  Each  arm  of  the  combined- 
arms  team  has  at  a  minimum  one  radio  network  and  the 
associated  dedicated  radio  assets  used  by  that 
representative  on  the  FiST.  The  information  regarding  the 
communications  that  support  the  fire  support  efforts  will  be 

5  Either  a  Naval  Aviator  or  Naval  Flight  Officer  with  current 
qualifications  who  earned  MOS  7502  serving  as  a  Forward  Air  Controller 
(FAC)  or  a  trained  observer  that  has  passed  all  certifications  and 
qualifications  and  earned  a  secondary  MOS  8002  as  a  Joint  Terminal  Air 
Controller  (JTAC)  ( NAVMC  3500.42,  2008). 
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separated  by  radios  and  systems,  which  together,  provide  the 
required  communications  to  conduct  fire  support. 

(i)  Radio  Assets.  Radio  assets  can  either  be 
vehicle-mounted  or  man-portable  (manpack) .  The  radio  assets 
included  in  this  work  will  be  limited  to  those  allocated  to 
the  FO  Team  and  the  rest  of  the  FiST  as  this  is  the  focus  of 
the  SMART  Fires  application.  The  FiST  also,  typically, 
requires  mobility,  so  radios  that  cannot  be  manpack  are 
seldom  used  by  the  majority  of  the  FiSTs.  The  exceptions  are 
FiSTs  tasks  organized  to  a  particular  mission  set  such  as 
the  Amphibious  Assault  Vehicle  (AAV)  company  or  a  company  of 
M1A1  Tanks  in  support  of  a  maneuver  unit  that  is  required  to 
execute  a  portion  of  the  overarching  fire  support  plan.  The 
current  doctrinal  communication  networks  require  the  use  of 
High  Frequency  (HF)  ,  Very  High  Frequency  (VHF)  ,  and  Ultra 
High  Frequency  (UHF)  .  HF  networks  can  use  the  AN/PRC-150  (C) 
shown  in  Figure  4 . 


Figure  4.  AN/PRC-150 (C)  High  Frequency  Manpack  (From 

Harris  Corporation,  2011)  . 

VHF  assets  are  more  prolific.  As  such,  a 

greater  effort  by  the  acquisitions  community  has  been  placed 

on  reducing  the  size  of  the  manpack  VHF  radio  set.  Three 

primary  VHF-capable  radios  are  currently  used  and  they 

provide  both  VHF  and  UHF  capability  in  a  manpack  form.  The 
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three  radios  currently  used  for  both  VHF  and  UHF 
communications  are  the  AN/PRC-117F  VI (C)  Multi-Band  Multi- 
Mission  Manpack  Radios  (MBMMR)  shown  in  Figure  5,  the 
AN/PRC-148  V2 (C)  Multi-Band  Inter/Intra  Team  Radios  (MBITR) , 
and  the  AN/PRC-152  Multi-Band  Multi-Mission  Handheld  Radios 
(MMHR)  both  shown  in  Figure  6. 


It  is  not  uncommon,  when  conducting  FiST 
operations,  to  have  one  radio  to  support  the  81mm  mortar 
conduct  of  fire  (COF)  communications  network  and  two  radios 
for  simultaneously  monitoring  the  artillery  COF  voice  and 
data,  as  well  as  the  non-doctrinally-based  battery  fire 
coordination  (FSCOORD) .  The  latter  is  used  for  coordination 
between  FO  and  the  battery  Fire  Direction  Officer  (FDO) . 


Figure  5.  AN/PRC-117F  (C)  Multi-Band  Multi-Mission 

Manpack  Radios  (From  Harris  Corporation,  2011). 
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Figure  6.  AN/PRC-148  V2 (C)  Multi-Band  Inter/Intra  Team 

Radio,  (left)  and  AN/PRC-152  Multi-Band  Multi- 
Mission  Handheld  Radios  (right)  (From  Harris 
Corporation,  2011). 

The  FAC  or  JTAC  would  have  one  radio  for 
direct  UHF  communications  to  the  aircraft  providing  CAS,  and 
one  radio  for  VHF  communications  to  either  the  AO  at  the 
battalion  FSCC,  or  the  Air  Support  Element  (ASE)  or  Direct 
Air  Support  Center  (DASC)  at  the  Regiment  or  Division, 
respectively,  to  request  CAS  sorties  in  support  of  the  FiST. 

The  NGF  spot  teams  would  have  two  radios .  One 
radio  provides  HF  communications  to  the  ships  providing 
support  on  the  Naval  Ground  Spot  network  used  to  coordinate 
surface  fires  from  NGF  ships.  The  other  radio  provides  VHF 
communications  to  the  NGLO  at  the  battalion  FSCC  for 
coordination  of  missions  on  the  SFCP  local  radio  network. 


As 

previously 

discussed. 

the 

FiST  uses 

several 

different 

radios  and 

communication 

networks 

to 

properly 

apply  combined  arms. 

maximizing 

the 

lethality 

of 

the  MAGTF.  Different  components  of  the  FiST  are  each  charged 


with  coordinating  their  own  fire  support  activity  with  the 
overall  fire  support  plan  to  support  the  infantry  maneuver. 
For  example,  the  mortar  FO  coordinates  with  the  battalion's 
81mm  Mortar  platoon,  the  artillery  FO  team  coordinates  with 
the  supporting  artillery  battery,  and  the  FAC  or  JTAC 
coordinates  with  CAS  assets  on  station.  After  all  fire 
support  agencies,  mortars,  artillery  and  CAS  confirm  they 
can  simultaneously  support  the  fire  support  plan,  the  FiST 
leader  establishes  a  time-on-target  (TOT)  for  the  CAS  and 
the  timeline  for  mortars  and  artillery  is  established. 

The  FiSTs  deconflict  their  requested  missions 
by  submitting  them  to  the  battalion  FSCC.  The  battalion  FSC 
is  the  battalion  commander' s  appointed  representative  to 
approve  or  deny  fires  in  support  of  the  maneuver.  The  FSC  is 
the  final  authority  on  approval  of  fire  missions  by  the  line 
companies  and  requires  the  most  complicated  communications 
support  plan  at  the  tactical  level.  One  item  that  must  be 
considered  is  that  although  many  communications  experts 
believed  that  the  introduction  of  digital  (data) 
communications  would  decrease  the  number  of  radios  for  fire 
support,  it  actually  nearly  doubled  the  requirements.  It 
doubled  the  requirements  for  the  fire  supporters  due  to  lack 
of  trust  in  a  digital  device  producing  the  same  level  of 
results  as  the  traditional  voice  call  for  fire.  The  current 
and  doctrinal  nets  for  the  FiST,  FSCC,  mortar  platoon,  NGF 
ships  and  the  artillery  battery  to  maintain  are  shown  in 
Table  1 . 
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Legend: 

C  -  Net  Control 

X-  Guard 

R-As  Required 

MAGTF  FSCOORD  (VHF)*  | 

MAGTF  Arty  CMD  (UHF/VHF/HF)  j 

Infantry  Regt  FSCOORD  (VHF)  | 

Arty  Regimental  CMD  (HF)  | 

Arty  Regimental  FD  (VHF)*  [ 

Arty  Regimental  TAC  (VHF)  j 

GCE  Arty  Air  Spot  (VHF)  | 

Arty  Battalion  CMD  (VHF)  | 

Arty  Battalion  FD  (VHF)*  | 

Arty  COF  (VHF)*  | 

Arty  Battery  FSCOOR  (VHF)  | 

TAR(HF)  | 

TAD  (VHF/UHF)  | 

TACP  Local  (VHF)  | 

GCE  NGF  Support  (HF)  j 

NGF  Air  Spot  (UHF/VHF)  | 

NGF  Ground  Spot  (HF)  | 

NGF  Control  (HF)  | 

SFCP  Local  (VHF)  | 

MAGTF  NGF  Spot  (HF)  | 

Bn  Mortar  (VHF) 

Infantry  Bn  FSCC 

X 

R 

R 

X 

X 

X 

C 

R 

c 

C 

R 

X 

DS  Artillery  Battery 

R 

R 

X 

X 

X 

X 

R 

C 

C 

C 

R 

FO  Team 

R 

X 

R 

FAC 

R 

X 

X 

X 

Mortar  FO 

X 

NGF  SpotTeam 

X 

X 

NGF  Ships 

X 

R 

X 

X 

X 

Mortar  Platoon 

C 

Notes: 

*  Data  and/or  Voice  nets 

Table  1 .  Current  and  doctrinal  FSCOORD  nets  (After  MCDP 

3-16,  1999)  .  6 


(ii)  Data  Systems.  For  every  fire  support 
agency  that  could  provide  fire  support  to  the  line 
companies,  internal  standard  operating  procedures  actually 
required  redundant  voice  and  data  nets.  Specifically,  for 
artillery,  when  digital  communications  were  beginning  to 
enter  the  operating  forces  in  the  early  1990s,  the  AN/PSC-2 
Digital  Communications  Tool  (DCT) ,  shown  on  the  left  in 
Figure  7,  required  a  dedicated  VHF  radio  to  which  it  was 
tethered  via  cable  for  a  digital  Artillery  COF  net  and 
another  separate  VHF  asset  to  be  used  as  a  voice  COF. 


6  Self-generated  table  from  author' s  knowledge  of  internal  infantry 
battalion  and  DS  artillery  battery  operations,  with  doctrinal  support  by 
(MCWP  3-16,  1999)  . 


26 


This  doubled  the  COF  requirement  for  radios, 
since  parallel  communications  were  now  required  for  the 
submission  of  digital  CFFs  with  a  voice  confirmation  of 
receipt  or  clarification.  The  same  parallel  communications 
networks  are  now  required  for  the  NGF  Spot  Net  with  the 
advent  of  the  Naval  Fire  Control  System  (NFCS) .  This 
provides  digital  communications  between  the  ship  providing 
fire  support  and  either  the  spotter  or  the  firing  battery 
with  an  AN/PSC-13  D-DACT,  shown  on  the  right  in  Figure  7,  or 
the  joint  fire  support  system  of  record  in  the  DoD,  the 
AN/GYK-47(V)  Advanced  Field  Artillery  Tactical  Data  System 
(AFATDS) ,  shown  in  Figure  8.  AFATDS  remains  the  gateway  for 
all  digital  communications  to  enter  the  current  FSCOORD 
architecture  in  the  Marine  Corps  for  the  foreseeable  future. 


Figure  7.  On  the  left  the  AN/PSC-2  Digital 

Communications  Terminal  (From  Ebay,  2011)  and  on 
the  right  the  AN/PSC-13  Dismounted-Data  Automated 
Communications  Terminal  (From  Scott,  2006) . 
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Figure  8.  AN/GYK-47  (V)  Advanced  Field  Artillery 
Tactical  Data  System  (From  PM  FATDS,  2004)  . 

The  scope  of  the  previous  section  was  limited 
to  the  lowest  organizational  echelon  to  create  an 
understanding  of  the  CFF  process  at  the  tactical  level.  The 
tactical  CFF  model,  however,  can  be  traced  to  specific 
techniques,  tactics,  and  procedures  (TTP)  and  scenarios 
(more  or  less  restrictive  rules  of  engagement  (ROE) ) 
modeling  the  Fires  process  at  any  level  of  command  or  joint 
combined  service  environment.  It  is  this  organizational 
scope  that  led  to  the  tactical  CFF  model  and,  using  a 
restrictive  method  for  clearance,  forced  numerous 
coordination  actions  amongst  all  of  the  performers  at  the 
fire  support  organizations. 

C .  CFF  PROCESS 

The  voice  CFF  or  as-is  CFF  process  is  a  result  of 
several  factors.  The  factors  are  common  throughout  the 
author' s  experience  for  newly  established  support 
relationships  between  the  supported  infantry  battalion  and 


28 


the  supporting  artillery  battery.  These  factors  facilitate 
increased  and  continuous  coordination  interactions  between 
the  numerous  participants  using  centralized7  clearance  for 
the  Marine  infantry  battalion  with  a  Marine  artillery 
battery  providing  Direct  Support  (DS)  (MCWP  3-16,  1999)  . 

Centralized  clearance  is  the  most  restrictive,  requiring  the 
highest  degree  of  inter-level  coordination.  The  tactics, 
techniques  and  procedures  (TTPs)  modeled  are  also  very 
restrictive,  which  complement  restrictive  rules  of 
engagement  (ROE)  and  can  also  be  attributed  to  the  level  of 
fire  support  proficiency  at  the  battalion. 

1.  Process  Flow 

FO  Team: 

•  Gathers  target  data  for  inclusion  in  CFF, 
location,  relative  direction  &  distance,  target 
description . 

•  Formats  target  data  into  call  for  fire  format. 

•  Initiates  voice  communications  with  FiST  to  pass 
on  CFF  with  target  data. 


7  Centralized  is  opposite  of  decentralized  message  clearance  where 
the  CFFs  are  transmitted  directly  to  the  fire  support  agency.  The  FSCC 
monitors  CFF  transmissions  over  the  radio  net  and  positively  clears  the 
CFF  as  approved  or  denied  over  the  net  before  the  fire  support  agency 
can  provide  fires  on  the  target.  Centralized  clearance  requires  all  CFF 
transmissions  to  be  routed  through  the  FSCC.  The  CFF  will  then  be 
transmitted  from  the  FSCC  to  the  fire  support  agency  after  approval  by 
the  FSC.  Any  mission  received  by  the  fire  support  agency  from  the  FSCC 
is  approved  and  cleared  to  fire.  After  receipt  of  the  CFF,  by  the 
agency,  there  are  direct  communications  between  the  observer  and  the 
fire  support  agency,  and  the  FSCC  only  monitors  the  net  for  unsafe 
conditions  (MCWP  3-16,  1999)  . 
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FiST: 


•  Verifies  that  the  CFF  is  safe  to  be  fired.  In 
order  to  do  this  he  asks  the  question  first:  "Does 
the  CFF  violate  any  known  Fire  Support 
Coordination  Measures8  (FSCMs) ?" 

•  If  the  answer  is  yes,  the  request  is  denied . 

•  If  the  answer  is  no,  then  FiST  Leader  proceeds 

with  processing. 

•  Validates  that  the  target  data  is  a  viable  target 
that  supports  the  current  infantry  scheme  of 
maneuver . 

•  If  the  answer  is  yes,  the  target  is  approved  at 

the  Company  level. 

•  If  the  answer  is  no,  the  target  is  denied . 

•  Conducts  low  level  weaponeering9,  validates 
whether  the  target  can  be  successfully  engaged 
with  the  company's  organic  asset, 

•  If  the  answer  is  yes,  the  CFF  is  transmitted  to 

60mm  mortar  platoon  for  prosecution. 

•  If  the  answer  is  no,  he  proceeds  with  processing. 

•  Performs  another  weaponeering  assessment  for  the 
appropriate  asset  to  prosecute  the  target. 

•  Formats  the  CFF  according  to  the  agency  being 
requested,  i.e..  Naval  Gunfire  CFF,  Close  Air 
Support  9-line10. 


FSCC : 

•  Verifies  whether  the  CFF  violates  any  FSCMs 

•  If  the  answer  is  yes,  the  request  is  denied . 


°  A  restrictive  FSCM  is  established  in  order  to  protect  friendly 
maneuver  units  or  protect  locations  that  should  not  be  directly  engaged 
with  fires  i.e.,  historical/religious  sites,  or  critical  infrastructure 
(MCWP  3-16,  1999) . 

0  Weaponeering  is  the  process  of  matching  targets  to  the  appropriate 
weapon  system  in  order  to  achieve  the  desired  effects  without 
squandering  resources  (MCWP  3-16,  1999) . 

10  The  formats  for  the  standard  CFF,  the  NGF  CFF  and  the  9-line  are 
provided  for  the  reader  in  Appendices  A,  B,  and  C. 
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•  If  the  answer  is  no,  he  proceeds  with  processing. 

•  Verifies  whether  the  CFF  is  formatted  properly  for 
the  agency  being  requested, 

•  If  the  answer  is  no,  the  CFF  is  denied  and  sent 
back  to  the  FiST  for  reformatting. 

•  If  the  answer  is  yes,  then  the  CFF  reguest 
proceeds  with  processing. 

•  Conducts  weaponeering,  validates  whether  the  FiST 
selected  an  appropriate  fire  support  agency  for 
the  target. 

•  If  the  answer  is  yes,  the  CFF  is  forwarded  to  the 
agency  as  approved . 

•  If  the  answer  is  no,  then  the  FSC  would  inform  the 
FiST  of  the  decision  to  assign  the  mission  to  a 
different  fire  support  asset,  then  properly  format 
the  CFF  for  the  new  asset  as  required. 

•  Verifies  whether  the  agency  being  assigned  is 
capable  of  firing  at  that  time. 

•  If  the  answer  is  yes,  the  CFF  is  forwarded  as 
approved . 

•  If  the  answer  is  no,  then  the  CFF  is  reformatted 
as  required  and  forwarded  to  the  next  available 
asset  as  approved . 

This  process  is  rehearsed  over  and  over  to  train  the 
fire  support  organizations  to  be  as  efficient  as  possible 
and  maximize  the  use  of  all  available  fire  support  assets. 
This  background  information  provides  the  necessary 
foundation  to  evaluate  the  limitations  of  the  current  fire 
support  systems,  both  the  digital  devices  and  the  extensive 
use  of  stove-piped,  at  most,  dual-banded  radio  assets.  In 
order  to  assist  this  research  a  business  model  of  how  the 
SMART  Fires  application  could  increase  unit  efficiency  was 
created  using  the  Savvion™  business  process  modeling 
software . 
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2. 


CFF  Sawion™  Model 


A  low  level  of  proficiency  at  the  FSCC,  FiST  or  FO  team 
level  will  cause  the  FSC  to  clear  all  missions  and  not  allow 
any  missions  to  be  sent  to  a  fire  support  agency  until  the 
CFF  have  been  approved  for  both  content  and  format.  In 
particular,  a  fire  support  team  with  low  proficiency, 
operating  under  restrictive  ROE  and  exercising  centralized 
clearance  is  the  most  restrictive  scenario  for  operations  at 
the  battalion  level.  This  was  the  situation  battalions  faced 
before  a  deployment  into  OEF.  It  is  essential  then  that  the 
CFF  Sawion™  model  simulate  this  all-too-common  situation  to 
demonstrate  the  direct  impact  to  the  joint  operating  forces. 
The  Sawion™  model  follows  the  sequence  of  individual 
actions  described  in  the  process  flow  section  of  this 
chapter . 


a.  As-Is  Process 

To  facilitate  a  deeper  understanding  of  how  the 

as-is  CFF  process  can  benefit  from  the  SMART  Fires 
application,  a  business  model  was  created  of  the  as-is 
process  using  the  Sawion™  software  application  and  is 
depicted  in  Figure  9.  The  model's  processes  and  actors  are 

shown  in  a  simplified  form  representative  of  the  actual  CFF 

process.  There  is  a  high  level  of  complexity  in  the  CFF 

process  modeled.  These  added  complexities  will  attribute  to 
a  greater  variance  in  the  times  associated  for  individual 
processes . 
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Figure  9. 


Savvion™  Model  of  the  As-Is  voice 
process . 


CFF 
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The  processes  represented  by  the  model  are  the 
specific  tasks  and  actions  that  must  be  taken  by  the 
respective  coordination  agent  in  order  to  provide  fire 
support  in  response  to  a  CFF.  The  Savvion™  model  can  provide 
information  about  where  lag  times  and  bottlenecks  occur  in 
the  As-Is  process.  These  bottlenecks  decrease  the  fire 
support  organization's  efficiency  and  slow  down  the  response 
times  of  the  fire  support  agencies.  The  Savvion™  model  is 
provided  along  with  results  from  the  simulation  of  the  As-Is 
process  in  Appendices  E  and  F  and  the  To-Be  process  G  and  H. 

Jb.  To-Be  Process 

The  results  of  the  modeling  effort  once  a  SMART 
Fires  application  are  implemented  into  the  training  scenario 
with  the  same  group  of  personnel  at  the  FO,  FiST  and  FSCC  by 
using  a  smartphone  device  that  takes  target  data  and 
converts  it  to  any  CFF  format  required.  Process  times  were 
reduced  due  to  the  implementation  of  the  SMART  Fires 
application' s  capabilities  and  integration  of  the 
smartphone's  positional  location  hardware,  large  display, 
touch  or  voice  input  capability.  Increased  situational 
awareness  was  also  provided  by  the  use  of  other  C2 
applications  that  display  real-time  locations  for  friendly 
units.  We  created  a  "To-Be"  process  model  of  how  the  ideal 
FO-to-FiST-to-FSCC  processes  might  be  improved  by  the  SMART 
Fires  application. 
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A  comparison  between  the  "As-Is"  model  and  the 
"To-Be"  model  demonstrates  initial  validation  for  the  SMART 
Fires  application,  thus,  assisted  scout  observers  may 
enhance  the  warfighting  capability  of  the  entire  fire 
support  organization  and  the  process  resulting  in  more 
responsive  fires.  The  Savvion™  model  for  the  "To-Be"  model 
is  provided  along  with  results  from  the  simulation  in 
Appendices  G  and  H. 

c.  Sawion™  Results 

The  comparison  of  the  As-Is  and  To-Be  Savvion™ 
models  demonstrated  that  a  SMART  Fires  application  capable 
of  integrating  smartphone  capabilities  into  the  existing 
fire  support  network  could  greatly  increase  efficiency  and 
warfighting  capability.  The  simulation  replicated  an  eight 
hour  training  evolution  for  an  infantry  battalion  conducting 
live  fire  training.  The  As-Is  model  produced  ten 
successfully  executed  CFFs .  The  To-Be  model  with  integration 
of  the  SMART  Fires  application  successfully  executed  one 
hundred  CFFs.  The  simulations  resulted  in  a  ten  times 
increase  in  the  efficiency  of  the  overall  CFF  process 
modeled.  These  results  help  conclude  that  the  FO 
capabilities  were  greatly  enhanced  with  the  smartphone 
running  the  SMART  Fires  application. 

Next,  we  present  the  current  smartphone 
integration  efforts  for  military  wireless  communications  and 
the  benefits  of  the  Android  platform  selected  for  the  SMART 
Fires  application.  Additionally  the  requirements  of  the  user 
are  matched  to  the  capabilities  of  an  Android  smartphone. 
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III.  SMARTPHONE  INTEGRATION 


This  chapter  provides  a  background  for  smartphone 
integration  into  military  wireless  communications.  The 
chapter  describes  both  commercial  and  DoD  efforts  to 
integrate  smartphone  technology.  It  further  provides  the 
reasons  why  the  Android  platform  was  selected  for  the  SMART 
Fires  application  as  well  as  a  detailed  explanation  of  how 
the  Android  OS  software  stack  best  supports  the  application. 
The  chapter  concludes  with  a  solution  to  current  fire 
support  limitations  in  an  analysis  of  how  the  SMART  Fires 
application  running  on  the  Android  OS  assists  the  users' 
tactical  mission  requirements. 

A .  PREVIOUS  EFFORTS 

Prior  to  selecting  an  SDK  for  development,  a  smartphone 
OS  had  to  be  chosen.  Research  was  conducted  into  existing 
smartphone  integration  and  the  operating  systems  used  in 
those  efforts.  These  previous  efforts  then  facilitated  a 
decision  for  the  OS  platform  that  best  suited  rapid 
development  of  the  SMART  Fires  application.  Our  research 
revealed  that  efforts  across  DoD  have  favored  two  OS 
platforms  over  the  variety  of  other  options,  namely:  Apple's 
iPhone  OS  and  Google's  Android  OS. 

1 .  Commercial  Integration 

Efforts  for  smartphone  integration  and  developmental 
exploration  have  come  from  numerous  sources  both  within  and 
outside  of  the  DoD.  The  results  and  products  are  varied; 
however,  the  focus  has  been  primarily  on  two  smartphone 
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platforms:  Apple's  iPhone  and  Google's  Android  OS.  Although 
corporate  efforts  are  not  limited  to  the  iPhone  and  the 
Android  systems,  these  efforts  were  available  for  public  and 
system  information. 

a.  General  Dynamics 

In  conjunction  with  Itronix,  General  Dynamics  (GD) 
has  created  the  GD300,  shown  in  Figure  11.  It  is  advertised 
as  a  rugged,  wearable  computer,  with  an  integrated  GPS  high 
gain  antenna  and  it  utilizes  the  Android™  open  operating 
system  (General  Dynamics,  2011) .  The  GD300  was  recently 
tested  in  a  simulated  operational  environment  exercise  held 
by  the  Army  to  test  the  operational  feasibility  of 
smartphone  integration  at  the  tactical  level.  This  testing 
of  the  GD300  was  conducted  using  the  Tactical  Ground 
Reporting  (TIGR)  application  installed.  This  type  of 
tactical  application  provided  real-time  positional  location 
of  friendly  forces  and  suspected  enemy  positions. 

The  GD300  and  the  TIGR  application  together 
provide  a  venue  for  the  acceptance  of  the  SMART  Fires 
application  once  fully  developed.  The  Android  based  OS  used 
for  the  GD300  if  proven  successful  would  be  the  optimum 
development  platform  for  the  SMART  Fires  application,  since 
the  existing  TIGR  application  could  provide  an  existing 
application  that  can  provide  both  friendly  and  suspected 
enemy  locations  both  of  which  are  reguired  to  safely 
deconflict  fires  and  initiate  a  successful  CFF. 
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Figure  11.  The  GD300  is  a  ruggedized  wearable  computing 

platform  using  the  Android  Open  Operating  System 
(From  General  Dynamics,  2011)  . 


Jb .  Lockheed  Martin 

The  MONAX©  system,  shown  in  Figure  12,  is 

developed  by  Lockheed  Martin  Corporation  and  is  an  iPhone- 

based  system  that  integrates  the  COTS  iPhone  smartphone  with 

a  MONAX  Lynx  sleeve  that  connects  the  smartphone  to  the 

MONAX  secure  network,  the  XG  BS  infrastructure.  This 

networking  infrastructure,  which  is  proprietary  to  Lockheed 

Martin,  is  advertised  to  provide,  via  mobile  ground  stations 

or  located  onboard  airborne  platforms,  commercial  cellular 

infrastructure  to  the  user.  The  MONAX  system  communicates 

using  a  non-traditional  RF  4G  cellular  signal  and  is  also 

capable  of  "exportable  military-grade  encryption"  (Lockheed 

Martin  Corp,  2010) .  The  MONAX  brochure  also  advertised  the 

availability  of  an  App  Store™  twenty-four  hours  a  day,  seven 
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days  a  week  for  users  of  the  MONAX  system.  The  applications 
available  at  the  time  of  the  brochure's  release  were 
described  as  having  the  ability  to  assist  the  warfighter' s 
situational  awareness  (SA)  and  C2 .  MONAX  believed  it 
achieved  this  by  providing  facial  recognition  software 
capability,  ISR  data  access,  and  automated  mission  reports 
(Lockheed  Martin,  2010)  . 


Figure  12.  Handheld  portion  of  the  MONAX  system  with 

MONAX  Lynx  sleeve  with  COTS  iPhone  (From  Lockheed 

Martin,  2010)  . 


c .  Raytheon 

Raytheon' s  efforts  into  the  military  smartphone 
integration  foray  came  in  2009  when  they  created  the  ill- 
fated  One  Force  Tracker™  application  for  the  iPhone,  and  the 
more  successful  Raytheon  Android™  Tactical  System  (RATS™) , 
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shown  in  Figure  13  (Raytheon,  2011)  .  Although  information  on 
the  company  website  was  limited,  the  One  Force  Tracker™ 
program  was  later  cancelled  in  2011,  however  the  RATS™ 
system  has  seen  continued  development.  The  RATS™  device  is 
designed  to  assist  intelligence  collaboration,  enable  real¬ 
time  full-motion  video  and  imagery,  and  harness  social 
networking  functionalities  to  enhance  situational  awareness 
using  Android™  open  software  architecture  (Woyke,  2009) . 
Although  the  RATS™  device  claims  to  be  the  first  device  to 
harness  the  Android  architecture,  there  have  not  been  any 
further  releases  of  information  about  the  RATS  program  from 
Raytheon  (Raytheon,  2011)  . 


Figure  13.  Raytheon's  RATS™  smartphone  device  for 

military  integration  (From  Raytheon,  2011). 

2 .  DoD  Efforts 

a.  Tactical  NAV 

The  first  public  attempt  to  integrate  smartphone 
technology,  specifically  application  development,  for  the 
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iPhone  OS  to  assist  the  tactical  warfighter  is  from  a  fellow 
artillery  officer  in  the  United  States  Army.  Captain 
Jonathan  J.  Springer  privately  funded  the  development  of  an 
iPhone  application  that  he  states  "is  just  as  accurate  as 
some  of  the  most  expensive  military  GPS  systems  that  are 
being  issued  by  our  soldiers  today"  (Thompson,  2011)  .  The 
application,  named  Tactical  NAV,  included  the  ability  to 
plot  and  plan  routes  for  patrols,  display  positional 
location  information  in  the  Military  Grid  Reference  System 
(MGRS)  that  is  commonly  printed  on  tactical  maps  issued 
within  the  military,  and  display  direction  in  MILS11  (Fox 
News,  2011) . 

Tactical  NAV  also  integrated  the  camera  resident 
on  the  iPhone  with  the  capability  to  stamp  photographic 
images  with  a  position  and  time.  Additional  features  of  the 
Tactical  NAV  included:  navigation  to  an  input  grid  location, 
Go-to-Grid;  ability  to  overlay  1  kilometer  grid  sguares  over 
satellite  maps;  a  night  mode  for  ease  of  view  in  low-light 
situations  without  the  bright  screen  giving  away  one's 
position;  and  position  sharing  via  e-mail.  Recently, 
Tactical  NAV  introduced  a  new  version,  2.0,  that  added 
improvements  to  the  GUI  and  added  navigational  functionality 
to  way-points.  It  is  currently  available  on  the  iTunes  App 
Store  for  $5.99  (Tactical  NAV,  2010). 


11  MILS  are  a  unit  of  angular  measure.  1  MIL  equals  l/6400th  of  a 
circle.  MILS  are  traditionally  used  in  military  units  where  the 
precision  of  angular  measurement  is  critical  to  mission  execution  i.e., 
artillery  and  mortars.  The  MIL  relation  formula  also  converts  angular 
measurement  into  a  measured  length,  since  at  a  distance  of  1000m,  1  MIL 
=  1  meter  (MCWP  3-16.6,  1998). 
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Tactical  NAV  was  a  private  venture;  however, 
application  development  by  the  Army  has  been  formalized  by  a 
new  program  of  record. 

Jb .  CSDA 

CSDA  is  an  ongoing  effort  in  the  ARCIC  that 
explores  the  value  of  using  smartphones  to  provide  soldiers 
applications  to  perform  everyday  functions  ranging  from 
administration  to  combat  operations (ARCIC,  2011).  CSDA' s 
approach  to  development  has  been  to  simultaneously  develop 
both  of  what  they  label  Generating  Force  and  Operating  Force 
applications . 

Generating  Force  applications  are  targeted  for  the 
new  trainee  or  for  augmenting  school  training  in  the 
classroom  with  an  application.  Two  respective  examples  are 
an  application  that  provided  mobile  access  to  the  Army  Blue 
Book12  and  the  Patriot  Missile  Crew  Drills,  which  enabled 
soldiers'  learning  by  use  of  a  virtual  soldier  in  the 
application.  The  Operating  Force  applications  include 
position  location  and  identification  reporting,  CFF  (no 
further  information  was  publicly  available  about  this  CFF 
application) ,  and  requests  for  medical  evacuation  (MEDEVAC) 
(ARCIC,  2011)  . 

The  most  unique  characteristic  of  the  development 
efforts  at  CSDA  is  that  the  soldiers  learn  how  to  program 
the  applications  themselves.  The  efforts  for  application 
development  at  CSDA  have  taken  place  on  both  the  iPhone  and 
Android  platforms.  Most  applications  are  available  for 

12  Army  Blue  Book  is  the  new  recruit  reference  issued  to  all  basic 
trainees  that  provides  information  on  Army  culture,  history  and 
regulations  (TRADOC  PAM  600-4,  2008) . 
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download  on  both  the  iTunes  App  Store  and  the  Android 
Marketplace.  Apps  for  the  Army  (A4A)  also  created  a 
repository  for  the  applications  submitted,  along  with 
instructions  on  development  techniques,  and  SDK  links  on  the 
Army  Marketplace  website,  which  is  accessible  only  by  DoD 
CAC13  holders.  An  image  of  the  site  is  shown  in  Figure  14. 
CSDA  proved  how  effective  their  methods  are  in  the  recent 
A4A  challenge  sponsored  by  the  Army  CIO/G-6. 


□|  U.S.ARMY  MARKETPLACE 
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Mission  Planning  2 
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Desktop  2 
^  Mobile  12 
lj|  Utility/Secunty  2 
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Figure  14 . 


U.S.  Army  Application  Marketplace  (From 
ARCIC,  2011)  . 


13  CAC  (Common  Access  Card)  or  more  commonly  known  as  the  Smart  Card, 
enables  the  user  to  encrypt  and  cryptographically  sign  e-mails, 
facilitating  the  use  of  Public  Key  Infrastructure  (PKI)  to  establish 
secure  online  connections  (CAC,  2011) . 
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The  A4A  Challenge  was  the  Army' s  first  internal 
application  development  challenge.  From  March  1,  2010,  to 
May  15,  2010,  53  applications  were  developed  and  submitted 
by  personnel  from  all  across  the  Army,  both  active  duty  and 
civilian.  A4A  demonstrated  how  crucial  the  integration  of 
the  warfighter  is  toward  a  successful  rapidly  developed 
application . 

C .  FIST 

Another  successful  effort  to  develop  and  integrate 
a  smartphone  application  came  From  Marine  Captain  Carrick  T. 
Longley.  His  effort  was  to  develop  the  Field  Information 
Support  Tool  (FIST)  system.  FIST  incorporated  the  power  of  a 
COTS  smartphone  and  the  availability  of  SDKs  to  create  a 
software  application.  Collect ,  and  tie  the  handheld  device 
running  his  software  application  into  an  information 
management  server  known  as  FusionPortal .  The  information 
gathered  from  Collect  and  other  intelligence  databases  was 
then  processed  and  displayed  in  a  usable  form  through 
FusionView  software  (Longley,  2010)  .  The  FIST  architecture 
is  shown  in  Figure  15. 
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Figure  15.  Diagram  of  the  FIST  components  and  its 
overall  architecture  (From  Longley,  2010). 

The  FIST  was  designed  as  an  intelligence 
collection  tool  that  could  be  used  in  scenarios  and 
operations  varying  from  Counter-Insurgency  Operations  (COIN) 
to  humanitarian  assistance  and  disaster  response  (HA/DR) 
(Longley,  2010).  Longley' s  developmental  efforts  were 
successful  in  the  creation  of  the  Collect  application  and 
the  integration  of  the  smartphone  to  address  a  capability 
gap  that  exists  with  the  inherent  latency  involved  in 
intelligence  fusion  operations.  It  is  this  tie-in  to 
existing  systems  that  SMART  Fires  must  emulate  to  ultimately 
provide  the  functionality  required  to  enhance  a  warfighting 
capability. 

B.  SELECTION  OF  THE  ANDROID  PLATFORM 

The  top  four  current  smartphones  OSs  are:  Google's 
Android  OS,  Research  In  Motion  (RIM)  from  BlackBerry, 
Apple's  iPhone  OS,  and  Microsoft's  Windows  Phone  OS,  as 
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shown  in  Figure  16.  According  to  the  information  in  the 
chart,  only  the  Android  platform  is  increasing  as  far  as  the 
user  base.  The  IPhone  market-share  appears  somewhat  flat. 
The  Android  platform  was  selected  as  the  target  platform  for 
this  proof-of-concept .  It  was  selected  for  the  following 
reasons : 

1)  The  growing  popularity  of  the  Android  OS  potentially 
translates  to  an  increased  user  intuition  toward  SMART  Fires 
usage.  This  increased  familiarity  results  in  decreased 
training  requirements  for  the  users  to  interact  with  the 
application  on  an  Android  device.  Thus,  new  users  will  not 
require  dedicated  familiarization  training  on  the  SMART 
Fires  platform,  as  is  currently  the  case  for  AFTADS,  due  to 
pre-existing  knowledge  about  the  Android  OS. 


Figure  16.  U.S.  Smartphone  Market  Share  by  OS  from 

February  2010  through  January  2011  (From  Goldman, 

2011) . 


2)  Android  SDKs  are  available  for  development  on  any  of 
the  top  three  personal  computing  operating  systems:  Windows, 
Apple,  or  Linux.  Android's  developmental  environment  was 
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available  at  no  cost  to  the  user  in  a  variety  of  SDKs  and 
IDEs,  all  of  which  allowed  for  rapid  testing  and 
implementation  on  any  smartphone  running  the  Android  OS 
without  having  to  purchase  either  a  new  computer  or  learn  a 
new  computing  environment.14 

3)  The  iPhone  development  would  require  the  use  of  the 
iPhone  SDK  that  runs  on  MAC  OS  X  and  the  Xcode  integrated 
development  environment  (IDE)  (Apple  Inc.,  2011).  This  would 
have  reguired  a  relatively  large  time  investment  to  learn  a 
new  computing  OS  and  would  have  slowed  the  overall 
development  efforts  toward  the  SMART  Fires  application 
prototype . 

4)  The  SMART  Fires  prototype  was  based  on  the  primary 
researcher' s  exposure  to  the  capabilities  for  Android 
development  during  the  Wireless  Mobile  Computing15  course 
offered  at  NPS .  In  two  months,  the  class  collectively 
integrated  (onto  a  smartphone  running  the  Android  OS)  an 
application  that  enabled  use  of  all  communication  methods 
resident  in  the  smartphone's  hardware.  This  same  type  of 
communication  hardware  usage  is  envisioned  for  the  future 
development  of  the  SMART  Fires  application. 

The  Android  architecture  provides  the  best  use  of  a 
smartphone's  capabilities.  Simply  put,  development  using  an 

14  The  author' s  primary  computing  experience  is  with  Windows-based 
computing  systems. 

1^  The  wireless  mobile  computing  class  laid  a  foundation  for 
understanding  the  inner  workings  of  commercial  GSM  cellular  networks. 

The  class  project  required  the  use  of  a  commercial  cellular  device  that 
would  provide  emergency  first  responders  with  voice,  video  feed,  chat, 
and  e-mail.  The  prototype  was  meant  only  to  demonstrate  the  capabilities 
that  exist  on  the  smartphone  and  how  very  few  times  they  are  all 
realized  to  their  full  potential. 
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Android  enables  greater  functional  use  of  the  smartphone 
because  of  Android's  open-source  nature.  Developers  for 
Android  routinely  leverage  the  devices'  internal  components 
to  their  full  capacity.  These  efforts  seem  stifled  in  IPhone 
OS.  Additionally,  the  Android  social  networking  for 
developers  provides  support  forums  for  the  exploration  of 
the  Android  environment.  These  open  forums  serve  as  a  venue 
for  peer-review  and  enhanced  collaboration,  much  the  same  as 
for  the  LINUX  OS. 

Linux  is  a  key  component  of  the  Android  architecture, 
and  Android  is  the  product  of  the  Open  Handset  Alliance 
(OHA) .  The  OHA  is  a  business  alliance  dedicated  to  the  open 
development  of  mobile  handsets,  enabling  the  developers  to 
implement  new  technologies  as  they  emerge  and  providing 
consumers  an  evolving,  richer  experience.  OHA  accomplished 
this  by  providing  developers  open  access  to  the  hardware  and 
the  source  code  in  the  Android  architecture  (Open  Handset 
Alliance,  2011) . 

C .  ANDROID  ARCHITECTURE 

Shown  in  Figure  17  is  an  illustration  of  the  Android 
architecture.  The  basic  Android  architecture  is  composed  of 
four  stacked  layers.  The  layers  are  examined  from  the 
bottom-up  to  demonstrate  the  applications'  interaction  with 
the  physical  hardware  on  the  smartphone  that  is  offered 
uniquely  by  the  Android  OS.  These  layers  are:  the  Linux 
Kernel,  Libraries  and  Android  Runtime,  Libraries  Framework, 
and  Applications. 
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Figure  17.  Android  operating  system  architecture  (From 

Borenstein,  2008). 


1 .  Linux  Kernel 

The  Linux  Kernel16  is  the  base  stack  and  it  is  what  the 
Android  architecture  uses  to  interface  the  applications  to 
the  device's  hardware,  i.e.,  the  processor,  memory,  RAM  or 
peripheral  devices.  The  Linux  Kernel  is  the  base  component 
for  the  rest  of  the  Android  OS  and  also  provides  core  system 
services,  including  security,  for  memory  and  processor 
management  (Android,  2011). 


16  Linux  Kernel  is  an  operating  system  released  under  the  GNU  Public 
License  version  2  (GPLv2) .  Linux  was  created  by  a  Finnish  computer 
science  student,  Linus  Torvalds,  in  1991.  It  is  a  prominent  example  of 
the  free  and  open  source  software  development  environments.  (IBM,  2011)  . 
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2a.  Libraries 


The  next  component  of  the  software  stack  is  the 
Libraries.  The  Libraries  component  contains  C/C++17  compiled 
code  libraries  that  provide  capabilities,  or  systems 
utilities,  to  the  application  stack  through  Application 
Framework  (Android,  2011) .  The  main  libraries  are: 

•  System  C  Library  provides  support  for  internal  C 
or  C++  code  execution 

•  Media  Libraries  support  playback  and  recording  of 
various  audio,  video,  and  still  image  formats 

•  Surface  Manager  manages  the  display  and  composites 
2D  and  3D  layers  from  the  applications 

•  LibWebCore  is  a  modern  web  browser  engine 

•  SQLite,  a  relational  database  engine 

The  Libraries  component  of  the  stack  also  contains  the 
Android  Runtime  component. 

2b .  Android  Runtime 


Android  Runtime  includes  libraries  for  the  Java18 
programming  language.  In  the  Android  architecture,  every 
application  runs  in  its  own  virtual  machine19  (VM)  .  This 


17  C/C++  are  both  languages  in  the  C  family  of  programming  languages, 
originally  developed  for  the  Unix  OS.  C  was  the  original  language  and 
C++  is  a  more  powerful  general  purpose  subset  of  the  C  language  that 
better  facilitates  ease  of  use  by  the  programmer  (Cprogramming.com, 

2011)  . 

18  Java  is  the  programming  language  developed  by  James  Gosling  at  Sun 
Microsystems.  Similar  to  C  and  C++,  Java  uses  a  simpler  object  model 
that  enables  Java  applications  to  run  on  any  Java  Virtual  Machine  (JVM) 
and  remain  platform  agnostic  (Oracle,  2011)  .  Compatible  platforms 
provide  a  translation  tool— an  interpreter— that  accepts  each  compiled 
Java  statement  (instruction) —or  byte-code— and  produces  the  necessary 
machine-level  instructions  to  execute  that  statement. 

19  Virtual  Machine,  or  virtual  device,  is  an  emulation  of  hardware  or 
software  configurations  modeled  on  existing  hardware  or  software 
(Android,  2011) . 
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separation  of  software  from  hardware  by  a  VM  allows 
applications  written  in  Java  to  remain  platform  agnostic. 
The  instance  of  VM  within  which  the  application  runs  is  not 
a  Java  VM  (JVM) .  Java  applications  typically  run  in  a  JVM  on 
a  desktop  or  laptop  computer  because  there  is  less  concern 
for  preserving  power  and  processing  consumption.  In  Android 
Runtime,  the  applications  run  in  their  own  instance  of  a 
Dalvik  VM, 20  This  VM  provides  optimum  performance  on 
platforms,  like  a  smartphone,  that  are  constrained  by 
limited  power  and  processor  speeds  (Borenstein,  2008) . 

3 .  Application  Framework 

The  Application  Framework  is  a  set  of  services  and 
systems  that  include: 

•  Views ,  which  can  be  used  to  build  applications  by 
organizing  the  GUI.  This  includes  lists,  grids, 
text  boxes,  buttons,  and  web  browser  embedding; 

•  Content  Manager  to  provide  access  to  data  from 
other  applications  and  sharing  of  internal  data; 

•  Resource  Manager  that  enables  access  to  non-code 
resources,  such  as  strings,  graphics  and  layouts; 

•  Notification  Manager  to  enable  custom  display  of 
alerts  by  applications;  and 

•  Activity  Manager  to  manage  the  lifecycle  of 
running  applications. 

The  Application  Framework,  an  open  development 
platform,  offers  the  environment  for  developers  to  build 
rich  innovative  applications.  These  innovative  applications 
can  then  take  full  advantage  of  the  smartphone  platform 


20  Dalvik  is  a  process  VM  written  by  Dan  Bornstein  that  enables  Java 
code  to  run  on  a  slow  CPU  with  relatively  little  RAM,  on  an  OS  without 
swap  space,  while  powered  by  a  battery  (Borenstein,  2008) . 
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through  the  use  of  SDKs  to  access  the  full  framework  APIs 
used  by  the  core  applications  (Android,  2011) . 

4 .  Applications 

Applications  provide  the  interface  to  the  user  for  the 
platform.  In  this  regard,  the  programmer  develops  an 
application  with  the  GUI  to  harness  the  capabilities  of  the 
device  that  enhances  the  user's  experience.  These 
applications  for  Android  are  written  by  the  developer  in 
Java . 

We  next  discuss  our  analysis  in  pairing  smartphone 

capabilities  to  user  requirements  to  determine  how  well 

these  requirements  are  met. 

D.  ANDROID -TO-USER  REQUIRMENTS  ANALYSIS 

To  demonstrate  how  Android  can  best  support  the 
requirements  of  the  SMART  Fires  application  user,  we  must 
first  establish  the  user's  requirements.  The  SMART  Fires 
application  is  envisioned  for  the  entry  level  user:  Fire 
Support  Man  (MOS-0861)  .  Requirements  for  this  user  are 

defined  in  this  analysis  as  the  required  tasks  to  be 
performed  in  combat.  All  artillery  Marines  are  assigned 

tasks  they  are  individually  required  to  perform  in  combat 
according  to  Marine  Corps  Order  3501. 26A,  also  known  as  the 
Marine  Corps  Artillery  Training  and  Readiness  (T&R)  Manual. 
We  conducted  this  analysis  with  the  list  of  the  required 
tasks  for  the  E-l  Private  MOS-0861  Fire  Support  Man 
according  to  this  T&R  manual. 
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1. 


Fire  Support  Man  METL 


The  task  list,  known  as  the  Mission  Essential  Task  List 
(METL) ,  is  segmented  into  several  categories  referred  to  as 
duty  areas.21  There  are  seven  duty  areas  for  Fire  Support, 
of  which  six  apply  to  the  proficiency  of  the  entry  level 

fire  support  man.  The  duty  areas  are  numbered  sequentially; 
however.  Duty  Area  06  is  not  within  the  scope  of  this 

analysis.  Therefore,  this  research  is  concerned  with  Duty 
Areas  01  through  05  and  Duty  Area  07.  The  Duty  Areas  are  as 
follows : 

•  Duty  Area  01-Map  Reading  and  M2  Compass 

•  Duty  Area  02-Communications 

•  Duty  Area  03-Observed  Fire  Procedures 

•  Duty  Area  04-Fire  Support  Planning  and 

Coordination 

•  Duty  Area  05-Counterfire22 

•  Duty  Area  07-Observer  Digital  Terminal 

These  duty  areas  comprise  the  Mission  Essential  Tasks 
(MET)  .  METs  are  further  differentiated  into  two  types.  Core 
and  Core  Plus.  Core  tasks  are  essential  individual  tasks 

that  support  the  warfighting  function  for  the  unit.  Core 
Plus  tasks  are  situation  dependant  to  the  warfighting 

function  of  the  unit  when  assigned  specialized  missions  or 
duties  (Goldman,  2010)  .  An  example  of  a  Core  versus  a  Core 
Plus  task  is: 

Duty  Area  03-Observed  Fire  Procedures 

21  Duty  areas  are  extracted  from  (MCO  3501. 26A,  2000)  and  the  excerpt 
of  the  specific  tasks  required  for  MOS  0861,  Private  through  Lance 
Corporal,  is  provided  in  Appendix  H. 

22  Counterfire  is  "fire  intended  to  destroy  or  neutralize  enemy 
indirect  fire  capability"  (MCWP  3-16,  1999) . 


54 


•  Core  Task:  0861.03.01  -  Select  an  observation  post 
and  prepare  to  use  it. 

•  Core  Plus  Task:  0861.03.42  -  Direct  a  Close  Air 
Support  (CAS)  strike. 

2 .  Smartphone  Assistance  for  METs 

The  scope  of  this  project  was  to  develop  and 
demonstrate  a  prototype  SMART  Fires  application  that  focused 
on  the  Core  Tasks  for  the  entry  level  MOS  0861.  A  table  was 
created  to  demonstrate  the  amount  of  assistance  an  Android 
device  running  the  SMART  Fires  application  could  provide  to 
the  user  to  accomplish  the  Core  METs.  These  Core  METs  became 
the  basis  of  the  SMART  Fires  application  requirements. 

a.  Smartphone  Features 

The  standard  smartphone  is  equipped  with  several 
hardware  components  that  provide  the  Smart  capability.  These 
features  include,  but  may  not  be  limited  to: 

•  Accelerometer 

•  Gyroscope 

•  Compass 

•  GPS 

•  Bluetooth™ 

•  WiFi 

•  Telephony 

•  Cameras 

•  Large  Touch  Display 

•  Accessible  Compact-Flash  Storage 

•  Large  internal  Memory  enabling  video  significant 

processing 

•  Capable  Processor,  most  are  now  1  GHz  or  greater 
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These  features  were  used  as  a  basis  for  evaluation  of 
the  functional  support  to  the  user's  MET. 

Jb.  Evaluation  of  Support 

The  evaluation  of  support  to  the  Core  METs  was 
done  from  two  perspectives  assuming  a  fully  developed  SMART 
Fires  application.  The  first  perspective  was  how  many  of  the 
smartphone  features  were  utilized  in  accomplishing  any 
portion  of  the  MET;  this  perspective  was  categorized  as 
feature  utilization.  The  second  perspective,  and  most 
important  to  the  study,  was  how  well  accomplishing  the  MET 
was  supported;  this  perspective  was  categorized  as  MET 
support . 


A  determination  was  made  as  to  whether  or  not  each 
smartphone  feature  could  provide  support  for  each  MET;  if 
the  answer  was  yes,  the  feature  was  awarded  a  one,  if  the 
answer  was  no,  the  feature  received  nothing.  The  total 
points  were  added  together  for  each  MET  and  the  sum  divided 
by  the  number  of  smartphone  features.  This  quotient 
reflected  the  percentage  of  the  smartphone  features  utilized 
for  that  MET.  This  process  was  repeated  for  all  METs.  Then 
the  average  for  all  Core  METs  was  taken  by  Duty  Area,  and  an 
average  of  70  percent  utilization  was  discovered.  This 
demonstrated  to  the  researchers  that  most  of  the  smartphones 
features  provide  benefit  to  the  user  in  enabling  the 
performance  of  the  Core  tasks.  The  most  important  question 
however,  is  how  well  a  fully  developed  SMART  Fires 
application  on  a  smartphone  would  support  the  user  in 
accomplishing  their  Core  tasks. 
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To  determine  the  level  of  support  to  the  METs  the 
researchers  assumed  an  ordinal  scale  that  corresponded  to 
the  level  of  support  provided  by  a  fully  developed  SMART 
Fires  application. 


•  If  a  MET  was  not  supported  in  any  way  the 
SMART  Fires  application  received  a  zero. 

•  If  the  MET  was  minimally  supported  the  SMART 
Fires  application  received  a  one. 

•  If  the  MET  was  mostly  supported  the  SMART 
Fires  application  received  a  2. 

•  If  the  MET  was  fully  supported,  meaning  the 
entire  task  could  be  accomplished  using  only 
the  application,  then  it  received  a  three. 

Then  the  average  for  all  Core  METs  was  taken  by 
Duty  Area,  and  an  average  of  2.0,  mostly  supported,  was 
discovered.  Also  key  to  the  evaluation  of  support  is  the 
fact  that  there  was  no  Core  Task  that  was  not  at  least 
minimally  supported.  The  average  utilization  and  MET  Support 
for  the  Core  Tasks  by  Duty  Area  is  shown  in  Table  2. 
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Duty  Area 

Feature 

Utilization 

Average 

MET 

Support 

Average 

01 

Map  Reading  &  M2  Compass 

80% 

1.8 

02 

Communications 

70% 

1 . 9 

03 

Observed  Fire  Procedures 

88% 

2 . 6 

07 

Observer  Digital  Terminal 

43% 

1.6 

ALL  CORE  METs 

70% 

2.0 

Table  2 .  The  table  presents  a  summary  of  smartphone 

utilization  and  support  to  the  Core  METs  by 

Duty  Area. 


These  figures  informed  the  researchers  that  a 
fully  developed  SMART  Fires  application  would  leverage  a 
significant  portion  of  the  platform  capabilities  for  fire 
support  at  the  tactical  level  and  it  would  enhance  the 
user' s  ability  to  perform  every  mission  essential  task  in 
combat.  In  the  evaluation,  the  utilization  average  was 
relatively  low  for  Duty  Area  07,  Observer  Digital  Terminal 
(ODT) ,  because  the  assumption  for  the  evaluation  was  that 
the  ODT  was  not  the  SMART  Fires  application.  This  assumption 
was  introduced  to  the  evaluation  since  the  SMART  Fires 
application  was  not  yet  developed  when  the  T&R  manual  was 
written.  This  research  effort  considers  that  the  best  ODT 
would  be  a  fully  developed  SMART  Fires  application.  As  proof 
of  this  belief,  if  the  ODT  were  assumed  to  be  the  SMART 
Fires  application  the  utilization  and  MET  Support  average 
would  have  increased  from  72  percent  to  7  6  percent 
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utilization  and  2.0  to  2.1  MET  Support.  Comparison  of  the 
utilization  and  MET  support  provided  by  the  SMART  Fires 
application  for  Core  Tasks  is  provided  in  Appendix  I  and  for 
the  Core  Plus  tasks  in  Appendix  J. 

E.  RAPID  DEVELOPMENT  DEFINED 

We  began  rapid  development  of  the  SMART  Fires 
application  prototype  by  establishing  requirements.  The 
underlying  premise  for  the  proof-of-concept  study  was  that  a 
user  could  aid  in  the  rapid  development  of  the  prototype 
application  that  could  then  be  provided  to  the  operating 
forces,  enhancing  warfighter  capability.  To  demonstrate  this 
we  first  needed  to  discover  what  user  input  would  be  most 
beneficial  to  the  developer. 

1 .  User  Involvement 

Software  development  for  mobile  applications  in 
particular  is  still  in  its  infancy  when  contrasted  with 
software  development  in  general  that  started  in  the  late 
1960s  and  has  been  around  for  more  than  50  years  (Osmundson, 
2011)  .  Traditionally,  a  software  developer  is  not  in  the 
military  operating  forces.  The  developer  relies  on  past 
personal  experience  and/or  the  advice  of  systems  engineers 
and  software  developers  for  how  to  best  satisfy  requirements 
-  usually  to  the  detriment  of  the  user. 

Often  the  software  developer  satisfies  internal 
production  requirements  at  a  higher  priority  than  the  users' 
requirements.  It  is  essential  that  detailed  requirements  be 
given  to  the  developer  to  create  software  that  fulfills  the 
user's  needs.  Therein  lies  the  problem  with  traditional 
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development  methods:  users  are  seldom  capable  of 
articulating  the  software  requirements. 

User  requirements  are  difficult  to  articulate,  in  part 
because  the  user  does  not  have  an  in  depth  knowledge  of  the 
capabilities  of  the  system  platform  for  which  the  developer 
will  create  the  software  application,  may  not  exist.  This  is 
not  generally  the  case  in  smartphone  application 
development;  the  user  and  the  developer  both  have  a  detailed 
knowledge  of  the  platform  and  interface.  The  introduction  of 
the  user  as  a  partner  in  development  is  what  will  be 
exploited  in  the  SMART  Fires  application  prototype. 

We  argue  that  that  by  adapting  existing  software 
development  practices  to  the  development  of  a  smartphone 
application,  the  development  time  could  be  decreased  and  a 
fielded  product  provided  to  the  warfighter  sooner.  An 
examination  of  current  prototyping  is  required  to  understand 
how  it  was  adapted. 

a.  Rapid  Application  Development 

There  exists  an  industry  accepted  methodology  for 
prototyping  in  software  development  known  as  Rapid 
Application  Development  (RAD)  (Christensen  &  Thayer,  2001). 
The  process  takes  place  in  a  cycle  with  three  steps.  The 
cycle  begins  with  the  user's,  or  customer's  (in  the  business 
case),  provided  requirements  for  the  prototype.  Next,  the 
developer  builds  the  prototype  based  on  these  requirements. 
The  cycle' s  last  step  is  the  prototype  usage  by  the 
customer.  The  cycle  runs  full  course  when  inputs  from  the 
customer  on  the  prototype  are  provided  to  the  developer  as 
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subsequent  requirements  for  the  prototype  (Osmundson,  2011). 
An  illustration  is  shown  in  Figure  18. 


Figure  18.  The  Rapid  Application  Development  Cycle  (From 

Osmundson,  2011)  . 

We  remain  convinced  that  the  strength  of  user 
inputs  to  the  application  did  not  fully  reveal  the  complete 
benefit  to  the  RAD  cycle  until  the  second  time  the  developer 
"listened"  to  the  user  as  illustrated  in  Figure  18.  This 
meant  lost  time  to  the  development  process.  The  answer  to 
reduce  this  lost  development  time  would  be  to  introduce  high 
value  input  requirements  when  initiating  the  cycle. 

Jb.  Rapid  Development  for  Applications 

There  are  two  key  differences  between  the  user  of 
the  current  call-f or-f ire  system  and  the  SMART  Fires  user. 
The  first  difference  is  the  previous  experience  with  the 
application  platform,  an  Android™  smartphone.  The  second 
difference  is  how  the  user  expected  to  interact  with  the 
SMART  Fires  GUI.  The  unique  benefit  of  the  user  in  rapid 
development  for  applications  is  that  the  user  provides  a 
visualization  of  a  GUI  intuitive  for  the  user  that  serves  as 

a  framework  for  the  application  requirements  and  interface. 
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The  developer  can  then  provide  a  prototype  that  meets  user 
needs  in  one  cycle  with  only  minor  changes  required  on  any 
subsequent  cycles.  This  rapid  development  for  applications 
technique  can  result  in  a  developer  creating  an  application 
the  user  already  knows  how  to  employ.  Unfortunately  for  the 
operating  forces,  this  familiarity  with  new  systems  is  the 
exception . 

Fielding  of  fire  support  systems  in  recent  history 
has  relied  on  New  Equipment  Training  Teams  (NETT)  to  provide 
the  users  with  the  minimum  requisite  knowledge  to  introduce 
a  new  capability  to  the  unit.  It  then  is  incumbent  on  the 
military  commands  to  develop  and  institutionalize  formal 
courses  and  recommended  on-the-job  training  practices  to 
gain  the  full  benefit  of  a  new  system  fielded23.  Our  rapid 
application  development  technique  can  reduce  this  lag  in 
operational  enhancement  to  the  warfighter. 

The  user  for  SMART  Fires  needed  to  convey  their 
requirements  to  the  developer  in  a  form  that  benefits  the 
development  of  the  application  as  quickly  as  possible.  The 
information  required  to  go  into  the  application  was  the  same 
as  for  the  standard  OFF.  Thus,  the  standard  OFF,  provided  in 
Appendix  A,  was  used  as  the  basis  of  information  that  a  user 
would  be  required  to  input  into  SMART  Fires. 

The  author' s  experience  provided  a  thorough 
understanding  of  voice  procedures  to  submit  the  CFF.  The 
inputs  to  the  CFF  were  known  to  be  required  inputs  into  the 
SMART  Fires  application  before  a  CFF  could  be  submitted 


23  Based  on  the  author' s  experience  while  serving  as  a  Battery 
Commander  and  the  Regimental  Logistics  Officer  during  the  fielding  of 
two  new  weapon  systems  and  the  planning  for  the  fielding  of  a  third. 
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using  the  new  application.  Many  inputs  could  be  extracted 
directly  from  the  Android  smartphone  functions  and  could  be 
provided  to  the  user:  location,  observer  identification,  and 
identification  of  the  firing  unit.  Yet,  the  target  location 
and  description  would  change  for  most  targets.  The  strength 
of  the  Android  development  is  the  ability  for  an  application 
to  take  information  from  other  C2  systems;  information  such 
as  other  friendly  unit  locations,  suspected  enemy  locations, 
or  known  enemy  activity  helps  facilitate  a  more  informed 
decision  by  the  observer. 

c.  App-boards 

The  Appboards  technique  was  derived  from  how 
movies  and  animated  films  are  first  presented  to  the 
writers,  cinematographers,  or  detailed  animators,  referred 
to  commonly  as  story-boards.  Story-board  artists  use  roughly 
drawn  still  images  of  key  scenes  to  present  to  the  rest  of 
the  staff  or  development  team  a  vision  of  the  finished 
product.  Story-boards  have  also  previously  been  used  in 
development  of  user  interfaces  for  other  software 
applications  by  IBM  (IBM,  2011) .  This  technique  was  adapted 
to  the  development  of  the  SMART  Fires  application  by 
creating  App-boards. 

App-boards  are  hand-drawn,  roughly  illustrated 

screen  captures  of  the  application  being  designed.  The  app- 

boards  provide  a  vision  of  the  application  that  makes  sense 

to  the  user,  and  through  the  use  of  screen  numbering  and  the 

notes  section,  the  user  can  write  down  what  functionality  is 

required.  The  app-boards  can  be  as  detailed  or  as  generic  as 

the  user  and  developer  jointly  determine  necessary  to  convey 

the  concept  being  depicted.  The  app-boards  can  be  as 
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detailed  as  including  interfaces  buttons,  pull  down  menus, 
settings  button  etc.  An  illustration  of  the  app-board  is 
shown  in  Figure  19. 


Screen  # 


Screen  # 


screen  nemingcan 
be  either  a  number 
or  naming 
convention. 


notes  section  is  used 
for  explanations  of 
itemfuncttionsor 
clarification  of  layout. 


Figure  19.  Example  of  App-board  worksheet. 
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There  are  various  forms  of  this  type  of  product  in 
the  Android  development  communities  and  forums.  These 
products  are  usually  referred  to  as  "wireframes."  The 
wireframe  drawing  is  then  used  to  create  a  design  for  the 
prospective  Android  application.  Tools  that  exist  for 
wire framing  range  from  hardcopy  graphic-document,  with  a 
phone  display  silhouette  like  the  app-board,  to  a 
downloadable  software  package  that  can  be  used  as  stand¬ 
alone  software  or  in  conjunction  with  an  IDE,  such  as  the 
Eclipse™  SDK. 

In  this  proof-of-concept  study,  the  user  was 
assumed  to  be  familiar  with  the  use  of  a  smartphone  and  not 


expected 

to 

be  involved  in 

actual  Java 

programming 

or 

required 

to 

interact  with 

the  Eclipse™ 

IDE.  For  these 

reasons , 

the 

app-boards  provided  the  fastest  method 

for 

communication 

of  the  user' s 

vision  of  the 

prototype . 

The 

developer  could  now  commence  work  on  the  prototype  with  the 
user' s  vision  communicated,  moving  the  research  efforts  one 
step  closer  to  the  SMART  Fires  application. 

F .  DEVELOPMENT  ENVIRONMENT 

The  Eclipse™  development  tool  has  been  mentioned  as  an 
SDK  and  now  an  IDE  for  Android  Development  but  it  can  be 
used  for  much  more.  Provided  is  a  description  of  Eclipse  and 
its  capabilities  along  with  how  the  other  required  software 
components  tie  in  for  Android  development.  The  first  step  to 
setup  of  the  development  computer  was  installing  the  Java 
Development  Kit  (JDK) . 
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1. 


JDK 


On  the  Oracle  website  for  Java  development  there  are 
several  options  for  download  in  order  to  begin  development. 
All  the  software  downloaded  from  the  Oracle  website  was 
available  at  no  charge.  The  Java  Runtime  Environment  ( JRE) , 
required  for  Java  applications  and  applets,  is  also  required 
for  Android  development,  as  is  the  Java  Development  Kit 
(JDK)  .  There  are  several  open  source  versions  of  both  the 
JRE  and  JDK  available  however  this  research  effort  selected 
the  JRE  and  JDK  from  Oracle.  Without  a  version  of  the  JRE 
and  JDK  installed  the  IDE  selected  for  development  could  not 
use  the  Java  language  for  its  software,  since  it  is  the  JRE 
and  JDK  that  allow  for  the  respective  running  and  writing  of 
the  Java  programming  language  (Oracle,  2011) . 

Java  does  provide  its  own  Java  IDE,  NetBeans™,  which 
provides  most  of  the  same  functionality  as  the  Eclipse  IDE. 
The  Eclipse  IDE,  however,  is  widely  supported  in 
documentation  and,  specifically,  in  the  Commonsware© 
reference  library  used  by  the  researchers.  The  support 
aspect  weighed  heavily  in  the  decision  to  begin  development 
with  the  Eclipse™  IDE.  Accordingly,  the  next  step  toward 
development  was  to  download  the  Eclipse™  IDE. 

2.  Eclipse™  IDE 

The  Eclipse™  integrated  development  environment  began 
as  a  not-for-profit  corporation  that  furthered  open  source 
software  development.  Eclipse  is  provided  free  of  charge  for 
public  or  commercial  development.  The  infrastructure, 
maintained  at  no  charge  to  developers,  includes:  code 
repositories,  databases,  mailing  lists  and  newsgroups,  and 
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the  website  front  end  that  enables  downloads  of  the  Eclipse™ 
software  (Eclipse  Foundation,  2011).  The  Eclipse  software 
supports  development  in  a  variety  of  programming  languages 
in  addition  to  Java.  These  other  programming  languages 
include:  AspectJ,  C  and  C++,  COBOL,  and  PHP .  Eclipse  offers 
IDEs  for  these  languages  on  the  three  big  personal  computing 
OS:  Windows,  Linux  and  MAC.  The  other  main  feature  of  using 
the  Eclipse  environment  is  the  additional  tools  and  builds 
and  plug-ins  available  to  enhance  developmental  efforts.  The 
additional  tools  include:  tester  toolkits,  Google  plug-in 
(that  include  the  Android  Development  Tools  (ADT) ,  and  over 
1000  more  tools  (Eclipse  Foundation,  2011)  . 

The  Android  Development  website  specifically  recommends 
the  use  of  the  Eclipse  IDE  with  the  ADT  plug-in  for 
developers  new  to  Android  (Android,  2011)  .  The  researchers' 
exposure  to  the  mobile  computing  application  development 
provided  exposure  to  the  Mark  Murphy  CommonsWare©  library  of 
resources.  The  use  of  Eclipse  is  not  required  to  follow  the 
examples  provided  in  the  CommonsWare©  tutorials  and  lesson 
examples;  however,  the  lessons  were  significantly  easier  to 
understand  and  implement  when  using  the  same  IDE  as  the 
reference.  Eclipse™  was  most  appropriate  for  the  development 
of  our  SMART  Fires  prototype.  The  steps  to  download  were 
straight  forward  and  simple  to  follow  from  the  Eclipse 
website . 

3 .  Android  SDK  Starter 

After  installing  JDK  and  the  Eclipse  IDE,  next  comes 

the  Android  SDK  starter  package  with  Android  Development 

Tools  (ADT)  and  an  emulator,  the  Android  Virtual  Device 

(AVD)  .  The  AVD  allows  development  without  a  physical 
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smartphone  by  use  of  an  emulated  Android  smartphone  to  test 
and  trouble-shoot  the  application  being  developed.  Again, 
all  software  downloaded  from  the  Android  developer  website 
was  available  free  of  charge  and  on  the  three  main  personal 
computing  OS  choices. 

4 .  ADT  Plug-in  for  Eclipse 

The  ADT  plug-in  for  the  Eclipse™  IDE  allows  access  to 
the  ADT  and  the  AVD  software  directly  when  running  Eclipse. 
During  the  setup  for  the  plug-in  the  developer  is  reguired 
to  select  the  platforms  and  APIs  used  in  development  and  the 
ADT  downloads  those  APIs  for  use.  These  APIs  and  tools  allow 
full  functionality  for  development  and  trouble-shooting 
directly  from  within  the  Eclipse  workspace,  so  familiarity 
with  a  new  platform  is  not  required. 

G.  CREATING  WITH  COMMONWARES  REFERENCE 

The  Android  Development  reference  material  written  by 
Mark  Murphy  and  the  CommonsWare (LLC)  community  enabled  this 
research  effort  to  develop  the  SMART  Fires  Application 
through  a  paid  warescription  to  the  CommonsWare  online 
library  (CommonsWare,  2011).  The  warescription  provides  four 
books,  viewable  with  any  web  browser  in  three  formats,  Adobe 
Acrobat,  Amazon'' s  Kindle,  and  Electronic  Publication  (EPUB)  , 
the  latter  being  an  open  standard  for  electronic  readers  and 
some  web  browsers.  The  warescription  included  free  version 
updates  for  the  duration  of  the  warescription,  online  office 
hours  with  Mark  Murphy  via  a  chat  room  connection,  private 
consulting  (at  additional  cost) ,  source  code  for  all 
tutorials,  and  access  to  in-person  training  through  locally 
hosted  workshops. 
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The  CommonsWare  materials  were  purchased  by  the 
researchers  at  a  relatively  minimal  cost  of  $40.  The  return 
on  the  researcher' s  investment  was  reduced  time  in  the 
learning  of  a  new  programming  language.  The  time  expended 
the  prototype  development  was  also  reduced,  adding  to  the 
return-on-investment  for  the  CommonsWare  material,  since  the 
texts  provide  examples  and  tutorials  using  the  Eclipse  IDE. 
There  were  a  variety  of  other  products  available,  too,  such 
as  written  texts  and  videos,  the  latter  available  at  no 
charge  via  YouTube  (LLC)  .  The  products  however,  did  not 
include  the  interaction  with  the  Eclipse  IDE  in  the  depth 
that  was  covered  in  the  CommonsWare©  reference  library.  The 
research  effort  was  greatly  assisted  through  the  use  of  this 
resource  and  as  such  it  is  recommended  as  a  reference  for 
individual  learning  or  augmentation  to  formal  coursework. 

With  a  design  and  development  methodology  and  capacity 
established,  the  requirements  and  GUI  design  for  the  SMART 
Fires  application  prototype  can  be  addressed.  The  next 
chapter  describes  the  design  and  resulting  implementation  of 
this  smartphone-based  CFF  tool. 
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IV.  SMART  FIRES  DESIGN 


The  App-boards  created  during  the  design  process  that 
consolidated  user  requirements  and  an  initial  GUI  design  are 
provided  below.  The  chapter  further  provides  the  GUIs 
created  by  the  researchers  according  to  the  app-boards  laid 
out  for  the  SMART  Fires  application  prototype. 

A.  DESIGN  PLAN 

The  design  plan  for  the  SMART  Fires  application 
prototype  consisted  of,  first,  allowing  the  user  to  create 
the  app-boards  to  enable  the  developer  to  understand  the 
user' s  requirements  and  translate  them  into  application 
processes.  The  processes  can  then  be  programmed  and 
integrated  with  an  appropriate  GUI  design,  as  the  user 
conveyed  in  the  app-boards . 

1.  Requirement  to  Processes 

The  app-boards,  created  by  the  user,  describe  the 
anticipated  layout,  the  expected  interface  behaviors,  and 
the  requirements  for  the  application  based  on  warfighting 
experience.  The  SMART  Fires  application  prototype  is  aligned 
to  the  user  requirements,  as  shown  in  the  SMART  Fires 
application  process  depicted  in  Table  3.  Table  3  does  not 
contain  requirements  for  Duty  Areas  04  and  05  because  these 
areas  do  not  contain  any  Core  METs .  This  process  is  modeled 
after  the  Advanced  Field  Artillery  Tactical  Data  System 
(AFATDS)  process  and  user  requirements,  as  documented  in 


71 


research  by  Geoffrey  Thome.  His  research  explored  the 
systems  integration  of  AFATDS  and  the  Information  Operations 
Server  (IOS)  (Thome,  2002). 


Duty  Area 

User  Requirements 

SMART  Fires  process 

•  Maintain  current 

•  Receive  current 

01 

battlespace  geometry 

battlefield  FSCMs 

Map  Reading  & 

•  Maintain  accurate  user 

M2  Compass 

location 

•  Digital  communications 

•  Establish  comms 

•  Manage  Alerts 

•  Auto-Forward  CFF 

02 

•  Broadcast  position 

Communications 

•  Voice  communications 

•  Provide  simultaneous 
voice  and  digital 
communications 

•  Maintain  accurate 

•  Receive  friendly  unit 

friendly  unit  information 

information 

•  Deliver  Fires 

•  Perform  FSCM  checks 

•  Determine  recommended 
fires  support  agency 

03 

•  Format  CFF  info  into 

Observed  Fire 

any  digital  format 

Procedures 

•  Transmit  the  CFF  in 
format  acceptable  to 
any  fire  support  agency 

•  Receive  MTO 

•  Conduct  subsequent 
corrections 

•  Transmit  RREMS 

•  Maintain  digital  user 

•  Access  local  or  cloud 

07 

manuals  and  references  for 

storage  for  interactive 

Observer 

special  equipment  or 

learning 

Digital 

procedures  (Core  Plus 

•  Voice  recognition 

Terminal 

tasks ) 

searches 

Table  3.  User  requirements  translated  into  process 

requirements  by  Duty  Area  (After  Thome,  2002)  . 
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2. 


User  GUI  Design 


The  app-boards  are  reviewed  to  illustrate  the  user' s 
inputs  for  GUI  design.  The  inputs  captured  in  app-boards  1-5 
directly  contribute  to  the  observer  process  depicted  in 
Savvion™  To-Be  model  presented  in  Figure  10.  The  MTO 
received  from  the  artillery  battery  will  populate  screen  11 
in  app-board  6.  Screen  12  on  app-board  6  and  all  of  app- 
board  7  are  not  depicted  in  the  Savvion™  model. 
Specifically,  we  noted  the  following  for  user  design: 

•  App-board  1,  provided  in  Figure  20,  shows  the 
startup  screen  and  what  the  application  should  do 
to  facilitate  the  CFF. 

•  App-board  2,  provided  in  Figure  21,  illustrates 
the  menu  screen  and  selection  of  the  firing  agency 
when  initializing  the  application. 

•  App-board  3,  provided  in  Figure  22,  is  the  input 
screen  for  the  fire  support  coordination  agency  in 
the  CFF  process  and  the  CFF  screen  to  initiate  a 
fire  mission. 

•  App-board  4,  presented  in  Figure  23,  represents 
how  the  user  expects  to  interact  with  the  SMART 
Fires  application  to  input  the  firing  agency  and 
observer  identification,  parts  1  and  2  of  the  CFF. 

•  App-board  5,  provided  in  Figure  24,  illustrates 
the  description  of  the  target  screen  and  parts  2 
and  3  of  the  CFF. 

•  App-board,  6  provided  in  Figure  25,  illustrates 
the  MTO  screen  that  the  user  will  receive  when  the 
firing  agency  processes  their  CFF,  and  the 
subsequent  corrections  screen  for  adjustments  by 
active  targets. 

•  App-board  7,  provided  in  Figure  26,  illustrates 
the  user' s  design  for  the  termination  of  the  CFF 
known  as  Record  as  Target,  Refine,  End  of  Mission, 
Surveillance  (RREMS) ,  and  the  transmit  screen  for 
a  completed  CFF. 
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Figure  20. 


Figure  21.  App-board  2  is  the  main  menu  screen  and 

firing  agency  selection  screen. 
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Figure  22.  App-board  3  is  the  screen  to  input  the  fire 

support  coordination  agency  and  the  CFF  menu. 
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Figure  23.  App-board  4  shows  parts  one  and  two  of  the 

four  CFF  screens. 
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Figure  24.  App-board  5  shows  parts  three  and  four  of  the 

four  CFF  screens. 
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Figure  25.  App-board  6  illustrates  the  MTO  screen,  and 

the  subsequent  corrections  screen. 
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Figure  26. 


App-board  7  illustrates  the  RREMS  screen,  and 
the  remaining  screen  element  for  screen  #12  in 

Figure  25. 


B.  SMART  FIRES  PROTOTYPE  GUI 


Using  the  development  environment  created  as  described 
in  Chapter  III,  we  easily  translated  the  app-boards  into 


screenshots  for  the  user  to  validate  and  provide  feedback 
according  to  the  rapid  development  for  application 
technique . 

An  example  of  the  GUI  created  from  these  app-boards  is 
shown  here  in  Figure  27.  The  final  GUIs  created  during  this 
development  are  provided  in  Appendix  K. 


-rr.u  ii  irv. 

Observer  Location 


ND  564  987 
Update  location 


Observer  ID 


Figure  27.  These  screenshots  from  the  SMART  Fires 

application  prototype  correspond  to  the  app-board 
created  by  the  user  in  Figure  20. 

The  SMART  Fires  application  developed  herein 
demonstrated  both  the  utility  of  the  Android-based 
smartphone  as  a  platform  for  hosting  custom  combat-relevant 
applications  and  the  effectiveness  of  the  rapid  prototyping 
for  application  development  methodology  in  generating  such 
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applications.  The  final  chapter  will  review  the  intent  of 


this  research  effort  along  with  its  findings 
conclusions,  and  identify  areas  that  warrant  further 
and  analysis. 


and 

study 
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V. 


RESULTS,  CONCLUSIONS,  AND  RECOMMENDATIONS 


This  chapter  presents  the  answers  to  the  questions  that 
guided  this  research  through  analysis  of  the  results  of  the 
proof-of-concept  study.  We  also  present  the  conclusions  as 
to  the  validity  of  the  SMART  Fires  application  and  the  way 
ahead  for  further  development  of  the  SMART  Fires 
application.  Then,  once  fully  developed,  the  chapter 
describes  how  SMART  Fires  can  lead  to  a  product  line  of 
SMART  applications  that  provide  warfighters  with  enhanced 
combat  capability  across  many,  and  perhaps  all,  functional 
areas . 

A.  RESULTS 

The  extent  of  the  results  from  this  proof-of-concept 
study  is  easily  measured  by  stipulating  how  well  the 
research  questions  were  answered  in  the  course  of  the 
effort.  The  questions  presented  in  Chapter  I  are  provided 
for  ease  of  review. 

•  How  can  COTS  software  developmental  tools  be  used 
to  produce  a  smartphone  application  to  aid  the 
transition  between  traditional  radio  equipment  and 
a  tactical  cellular  network? 

•  How  does  the  SMART  Fires  application  fit  into 
existing  and  future  Command  and  Control  platforms 
in  integrating  information  into  a  Common  Tactical 
Picture  (CTP)  that  will  assist  the  warfighter? 

•  How  effective  will  these  COTS  applications  be  in 
aiding  the  warfighter  (e.g.,  target  location 
precision,  request  latency,  situational  awareness 
increases,  and  efficiency) ? 
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1. 


TRANSITION  TO  TACTICAL  CELLULAR  NETWORK. 


This  first  research  question  is  a  two-step  process 
addressed  first  by  providing  specific  C2  functions  commonly 
resident  only  at  the  battalion  and  higher  levels  to  the 
company,  and  in  some  cases,  to  the  individual  Marine.  In 
keeping  with  the  CAPSET  5  UNS  by  Hastings,  there  exists  a 
need  now  for  these  C2  functions  by  the  Company-level  units 
and  below  (Hastings,  2009)  . 

By  developing  applications  that  run  on  the  smartphone 
platform,  we  fulfill  that  need.  This  will  facilitate  the 
second  part  of  the  answer  regarding  transitioning  to  a 
tactical  cellular  network,  which  is  the  bandwidth 
requirement  levied  by  providing  this  C2  capability  down  to 
the  USMC  company-level  and  below.  This  need  requires  an 
improved  communications  network,  one  previously  unused  by 
the  military,  namely  a  tactical  cellular  network.  To  gain 
full  C2  capability  at  the  company,  smartphone  systems  will 
be  required  to  access  information  resident  with  the  legacy 
systems  of  record.  This  information  can  no  longer  remain 
stove-piped  in  proprietary  systems.  The  tactical  smartphone 
integration  can  be  aided  by  demonstrating  how  these  legacy 
platforms  may  be  integrated  into  a  tactical  cellular 
network . 

2 .  ASSIST  THE  WARFIGHTER  IN  INTEGRATING  COMMON 
TACTICAL  PICTURE  (CTP) 

The  Android-based  GD300,  tested  at  the  Army  experiment 
discussed  in  Chapter  II,  was  tested  with  the  Tactical  Ground 
Reporting  (TIGR)  application.  TIGR  provides  near-real  time 
C2  at  the  individual  soldier-level,  similar  to  the  Blue 
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Force  Tracker  (BFT)  providing  position  of  friendly  vehicles 
and  CP  locations  in  the  Army's  Force  Battle  21  Command  for 
the  Brigade  and  Below  (FBCB2)  .  The  TIGR  application,  if 
loaded  onto  the  smartphone,  could  provide  the  observer 
instant,  accurate  positions  of  friendly  maneuver  units  in 
his  area  of  operations.  The  BFT  provides  a  near-real  time 
position  location  for  tactical  forces.  This  information  is 
an  example  of  the  integration  possible  by  the  SMART  Fires 
application.  We  envision  a  similar  functionality  to  that  of 
Google  Maps  where  information  is  filtered  so  as  not  to 
overwhelm  the  user  as  the  map  scale  is  increased.  Lower 
level  units  and  individuals  might  become  visible  as  the  map 
is  scaled  down  to  a  focused  area  of  responsibility.  This 
information  feed  —  focused  to  the  area  with  which  the  user 
is  concerned  —  is  the  best  example  of  how,  when  integrated 
on  the  tactical  cellular  network  or  tethered  into  the  C2 
network,  SMART  Fires  can  enhance  the  user' s  Common  Tactical 
Picture . 

3.  EFFECTIVE  COTs  DEVELOPED  APPLICATIONS 

The  development  of  a  SMART  product  line  of  applications 
for  smartphones  will  provide  the  assistance  demonstrated 
through  the  Savvion™  business  model  in  Chapter  II.  The 
results  of  the  model  indicated  that  the  overall  efficiency 
of  a  unit  with  integrated  SMART  applications  could  prosecute 
ten  times  the  number  of  CFF  in  the  same  amount  of  time  as  a 
unit  without  the  applications. 

This  efficiency  in  execution  was  directly  related  to 

the  observer' s  ability  to  tie  in  information  from  the 

existing  C2  systems  like  Blue  Force  Tracker  (BFT) ,  which  is 

the  end  system  for  FBCB2  (Dixon,  2009)  .  This  same  product 

85 


line  of  "SMART"  applications  can  be  designed  for  every 
warfighting  function:  SMART  Intel,  SMART  Logistics,  etc.  A 
product  line  of  SMART  applications  could  be  developed  once 
the  SMART  APIs  are  made  available  for  development  similar  to 
the  way  developers  create  applications  to  interact  with  open 
source  APIs.  These  APIs  range  from  Google  Maps  to  Banking 
APIs.  Development  is  constrained  by  the  imagination  of  the 
user  community  with  respect  to  how  their  requirements  might 
be  addressed  by  smartphone-based  applications. 

B.  CONCLUSIONS 

This  thesis  explored  the  impact  that  smartphone-based 
applications  can  have  on  the  warfighter.  The  focus  of  the 
proof-of-concept  was  to  rapidly  design  an  application, 
leveraging  user  experience  with  C2  programs  of  record 
systems,  i.e.,  AFATDS,  Command  and  Control  Personal  Computer 
(C2PC) ,  Global  Command  and  Control  System  —  Marine  Corps 
(GCCS-MC) ,  to  enhance  the  Call-for-Fire  process  executed  by 
very  junior  Marines. 

Such  integration  efforts  for  a  military  smartphone 
technology  are  ongoing.  This  is  the  time  to  begin 
development  of  applications  that  provide  the  warfighter 
enhanced  warfighting  capability.  The  SMART  Fires  Application 
can  have  a  positive,  immediate  impact  on  the  warfighter's 
mobility  and  lethality.  It  is  in  this  integrated  Smartphone 
—military  tactical  network  environment— that  the  rapidly 
developable  Smartphone  applications  can  provide  a  positive 
impact  to  all  warfighting  functions  throughout  the  Marine 
Corps  and  eventually  the  joint  services. 
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C .  RECOMMENDATIONS 

In  the  course  of  this  research,  various  activities  were 
beyond  the  scope  established  for  the  proof-of-concept  study. 
Those  activities  should  be  considered  as  recommendations 
toward  the  completion  of  the  SMART  Fires  application 
prototype . 

1 .  AFTADS  Integration 

The  next  step  for  the  SMART  Fires  application  is  to 
complete  the  integration  into  the  existing  fire  support 
network.  The  CFF  from  SMART  Fires  requires  conversion  into 
the  Variable  Message  Format  (VMF)  for  transmission  to  the 
AFATDS .  This  task  presented  a  level  of  complication  and 
technical  expertise  that  was  beyond  the  scope  of  this 
research.  Through  further  development,  however,  the  SMART 
Fires  prototype  could  gain  the  required  functionality  and 
integration  with  existing  fire  support  C2  systems  as 
required  by  the  warfighter.  Such  would  mean  SMART  Fires 
could  transmit  a  CFF  directly  to  AFATDS  when  tethered  to  a 
COF  network  radio. 

2 .  Use  of  Augmented  Reality 

Some  existing  android  market  applications  integrate  an 
emerging  technology  known  as  Augmented  Reality  (AR)  .  AR  uses 
the  smartphone  framework  of  an  integrated  position  indicator 
and  accelerometer  to  provide  a  graphical  overlay  for  the 
device's  display  that  presents  relevant  information  to  the 
user,  such  as  current  position,  direction,  vertical  angles. 
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altitude,  etc.  The  closest  AR  application  that  matches  the 
display,  as  envisioned  by  the  researchers,  is  from  Hunter 
Research  and  Technology,  LLC,  named  Theodolite  Pro,  shown  in 
Figure  2  8 . 


Figure  28.  The  Theodolite  PRO  AR  screen  provides  a 

variety  of  positional  and  directional  information 
for  the  user  (From  Hunter  Research  &  Technology, 

2011) 


We  envision  that  the  primary  use  for  AR  would  be  in 
providing  a  visual  reference  of  critical  information  in  the 
display.  AR  can  be  used  in  a  military  application  to  present 
a  known  location  of  a  target  site  that  the  user  could 
readily  distinguish  on  the  display.  This  AR  function  could 
assist  the  user  to  verify  the  true  target  location  very 
quickly,  helping  to  avoid  unnecessary  collateral  damage. 

D .  FUTURE  WORK . 

The  SMART  Fires  application  prototype  could  benefit  the 
fire-support  community  immediately  with  increased  efficiency 
in  transmitting  a  CFF  in  any  format  or  standard  required. 
Future  work  for  the  SMART  Fires  application  could  establish 
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a  SMART  API  for  a  Product  Line  Architecture  (PLA)  of 
applications  to  increase  sharing  of  the  users'  CTP  so  that 
users  of  sister  SMART  applications  can  provide  logistics, 
intelligence,  force  protection,  or  other  information 
pertinent  to  the  warfighting  functionalities  required  for 
the  user's  success.  An  increase  in  the  user's  accuracy  and 
precision  in  target  location  could  also  be  provided. 
Finally,  a  SMART  Simulator  could  further  extend  the  training 
environment  for  our  users. 

1 .  SMART  Product  Line  Architecture 

The  Android-based  operating  system  used  on  the  GD300 
was  reported  to  be  released  to  the  public  for  developmental 
efforts  in  July  2011.  The  warfighter  could  maintain  the 
status  quo  and  continue  to  carry  more  equipment  and  systems 
than  he  should  because  the  system  providers  continue  to 
create  new  proprietary  devices.  The  most  advantageous 
aspects  of  smartphone  integration  into  the  military  wireless 
network  are  that  smartphones  provide  a  PLA  approach  to 
tactical  interfaces  by  standardizing  the  device  platform. 
Once  this  framework  is  established,  products  will  continue 
to  be  developed  and  integrated  with  other  applications. 
Smartphone  integration  may  also  inform  and  standardize 
future  software  development  because  the  platform  has  already 
been  established. 

2 .  SMART  Range  Finder 

The  Call-f or-Fire  (OFF) ,  transmitted  through  the  SMART 
Fires  application,  is  dependent  upon  the  ability  of  the  user 
to  estimate  the  distance  to  the  target.  While  the  use  of  map 

APIs  and  overlays  can  enhance  the  user's  accuracy,  the  human 
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factor  remains  involved  in  initial  target  location.  To 
decrease  human  error,  the  use  of  a  laser  range-finding 
device  as  a  part  of  the  SMART  Fires  system  may  increase  the 
likelihood  of  the  first  rounds  fired  having  the  desired 
effect  on  the  target  and  could  contribute  toward 
conservation  of  ammunition.  We  also  note  that  the  device  can 
either  be  tethered  via  wired  or  wireless  communication  with 
the  smartphone  or  fully  integrated  into  the  hardware  itself, 
such  as  a  sleeve. 

3 .  SMART  Simulation 

The  software  developed  by  the  two  Naval  Postgraduate 
School  students  for  The  Forward  Observer  Personal  Computer 
Simulator  (FOPCSIM)  was  created  to  increase  CFF  training 
effectiveness  for  Marines  embarked  aboard  naval  ships.  The 
realistic  training  simulation  increased  exposure  to  the  call 
for  fire  process  and  the  tasks  associated  with  accomplishing 
the  observer  core  tasks  (Brannon  &  Villandre,  2002) . 

Their  research  and  creation  of  the  this  stand-alone 
program  resulted  in  a  system  that  was  later  tied  into 
existing  forward  observer  systems,  to  include  the  Training 
Set  Forward  Observer  (TFSO) ,  Closed  Loop  Artillery 
Simulation  System  (CLASS) ,  Forward  Observer  Training 
Simulator  (FOTS) ,  GUARDFIST  II,  and  eventually  the  DVTE 
where  the  trainer  first  created  a  virtual  environment  for 
training  the  forward  observers.  The  integration  of  a 
simulation  capability  into  the  SMART  Fires  application, 
similar  to  FOPCSIM,  might  further  enhance  the  warfighting 
capabilities  of  the  user. 
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APPENDIX  A 


ADJUST  FIRE  MISSION 

(Grid  Method) 

Observer:  “ _ this  is _ Adjust  Fire,  Over" 

(FDC’s  Call  Sign)  (Observer’s  Call  Sign) 

“Grid _ .  Over” 

(6-Digit  UTM) 

Target  Description  " _ "  (Target  Description,  Size, 

Activity) 

Method  of  Engagement  (Optional)  (Danger  Close,  Mark,  High 

Angle,  Ammo/Fuse  Type) 

Method  of  Fire  and  Control  (Optional)  (At  My  Command,  Time 
on  Target,  Request  Splash,  Request  Time  of  Flight,  “Over’’) 

FDC  may  challenge  after  they  read  back  the  above.  The 
observer  should  be  prepared  to  authenticate 

Message  To  Observer 

*=  Mandatory  Call 

Units  to  Fire*  (Firing  Unit,  Adjusting  Unit) 

Changes  to  Call  for  Fire  (If  Any) 

Number  of  Rounds*  (Per  Tube) 

Target  Number* 

Time  of  Flight  (Seconds) 

Given  After  Message  To  Observer 

“Direction _ ,  Over"  (Mils  or  Degrees,  Magnetic) 

Adjustments 

“Left/Right _ "  (Meters,  from  Impact  to  Observer 

Target  Line) 

“Add/Drop _ ”  (Meters,  Distance  from  Impact  to 

Target) 

Once  on  target  call:  “Fire  for  Effect,  Over" 

Mission  Completion 

“End  of  Mission, _ ,  Over.” 

(BDA  and  Target  Activity) 


Extracted  from  J-FIRE  (MCRP  3-16. 8B,  1997) 
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APPENDIX  B 


NGF  CALL  FOR  FIRE 

(Given  in  two  transmission) 
(Grid  Method) 


this  is 


Fire  Mission.  Target# 


Over" 


(Ship  Call  Sign)  (Observer’s  Call  Sign)  (Assigned  by  observer) 

“Grid _ .  Altitude _ .  Direction _ Over” 


(6-Digit  UTM) 
Target  Description 

Method  of  Engagement 

Method  of  Control 


(Meters  MSL) 


(Mils/Grid) 

(Target  Description.  Size, 
Activity,  Cover) 


(Danger  Close,  Ammo/Fuse 
Type,  #  Salvos.  #  Guns, 
Reduced  Charge,  TOT) 

(Fire  for  Effect,  Ship  Adjust, 
Spotter  Adjust,  Cannot 
Observe,  At  My  Command) 


Gun-Target  Line 


Message  To  Observer 

(From  Gun  To  Target) 


Ready/Time  of  Flight/Line 
of  Fire  (if  firing  Ilium) 

First  Salvo  at  Offset 

Summit 


Changes  to  Call  for  Fire 


(Time  of  Flight  in  Seconds) 

(Danger-Close  Missions  Only) 

(Max  Ord  in  Feet  for  Air 
Spotter.  Meters  for  Ground 
Spotter) 


Extracted  from  J-FIRE  (MCRP  3-16. 8B,  1997) 
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APPENDIX  C 


CAS  BRIEFING  FORMAT  (9-LINE) 

( O in  it  data  not  required,  do  not  transmit  line 
numbers.  Units  of  measure  are  standard  unless 
otherwise  specified,  ’denotes  minimum  essential  in 
limited  communications  environment.  BOLD 
denotes  readback  items  w  hen  requested.) 

Term  in  a  l  controller:  “ _ this  is _ " 

(Aircraft  Call  Sign)  (Terminal  Controller) 

*1  IP/BP:  “ _ ” 

*2.  Heading:  “ _ "  (Magnetic) 

(IP/BP  to  Target) 

Offset:  “ _ (Left/Right) 

*3.  Distance:  “ _ ” 

(IP-to-Target  in  Nautical  Miles/BP-to-Target  in  Meters) 

*4  Target  Elevation:  “ _ " 

(in  Feet/MSL) 

*5.  Target  Description:  “ _ ” 

*6.  Target  Location:  “ _ "  (Latitude/Longitude  or  Grid 

Coordinates  or  Offsets  or  Visual) 

*7.  Type  Mark:  “ _ ”  Code:  “ _ " 

(WP,  Laser,  IR,  Beacon)  (Actual  Code) 

Laser  to  Target  Line:  * _ Degrees' 

*8  Location  of  Friendlies:  “ _ 

Position  Marked  By:  “ _ " 

9.  Egress:  “ _ * 

Remarks  (as  appropriate):  “ _ " 

(Threats.  Restrictions,  Danger  Close, 
Attack  Clearance.  SEAD,  Abort 
Codes,  Hazards) 

“Time  on  Target  (TOT):  ' _ or  Time  to  Target  (TTT): 

“Stand  by _ plus _  Hack.' 

NOTE:  When  identifying  position  coordinates  for  joint 
operations,  include  the  map  datum  data.  DESERT  STORM 
operations  have  shown  that  simple  conversion  to 
latitude/longitude  is  not  sufficient.  The  location  may  be 
referenced  on  several  different  databases;  for  example,  land- 
based  versus  sea-based  data 


Extracted  from  J-FIRE  (MCRP  3-16. 8B,  1997) 
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APPENDIX  D 
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APPENDIX  E 


Simulation  Results 

Duration  7:21:00 

Time 

Process  Time  And  Cost 

1 

Process 

Scenario 

Instances 

Total  Cost 

Waiting  Time 
(Time) 

Total  Time 
(Time) 

Call  For  Fire 

Fire  Support 

10 

280.6 

9:21: 00 | 

17 : 07 : 00| 

Call  for  Fire 

Scenario 

Fire  Support 

Instances 

10 

Activity 

Performer 

Occurs 

Waiting  Time 
(Time) 

Time  To  Complete 
(Time) 

Total  Time 
(Time) 

Computes  Firing  Data 

All  member(s)  of  Artillery  Batte 

1 

0:01:00 

0:02:00 

0:03:00 

Costructs  Message  to  Observer 

All  member(s)  of  Artillery  Batte 

1 

0:00:00 

0:01:00 

0:01:00 

Receives  Arty  CFF 

All  member(s)  of  Artillery  Batte 

1 

0:00:00 

0:02:00 

0:02:00 

Assigns  Organic  Fires 

FiSTLeader 

1 

0:30:00 

0:01:00 

0:31:00 

Process  CFF 

FiSTLeader 

5 

6:32:00 

0:50:00 

7:22:00 

Requests  81mm  mortars 

FiSTLeader 

1 

0:03:00 

2:00:00 

2:03:00 

Requests  Arty 

FiSTLeader 

1 

0:00:00 

2:00:00 

2:00:00 

Requests  battalion  fires 

FiSTLeader 

3 

0:15:00 

0:09:00 

0:24:00 

Requests  NGF 

FiSTLeader 

1 

2:00:00 

2:00:00 

4:00:00 

Approves  81mm  mortar 

FSC 

1 

0:00:00 

0:01:00 

0:01:00 

Approves  Arty 

FSC 

1 

0:00:00 

0:01:00 

0:01:00 

FSCC  processes  CFF 

FSC 

3 

0:00:00 

0:06:00 

0:06:00 

Observer  gathers  target  data 

Observer 

5 

0:00:00 

0:05:00 

0:05:00 

Observer  submits  CFF 

Observer 

5 

0:00:00 

0:25:00 

0:25:00 

Records  MTO 

Observer 

1 

0:00:00 

0:01:00 

0:01:00 

Resource 

Unit 

Cost/Unit 

#  People 

Utilization 

Observer 

Hour 

12 

2 

0% 

FSC 

Hour 

31 

11 

0% 

FiSTLeader 

Hour 

20 

6 

0% 

All  member(s)  of  Artillery  Battery 

Hour 

14.25 

100 

0% 

Given  Information 

Work  Week  Hours  = 

40 
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Fire  Support  Coordinator  FIST  Leader 


APPENDIX  F 
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APPENDIX  G 


Simulation  Results 


iDuration  7:16:58  Time 


Process  Time  And  Cost 


Process 

Scenario 

Instances 

Total  Cost 

Waiting  Time 
(Time) 

Total  Time 
(Time) 

TOBE 

(default) 

100 

3345.77 

1:47:55 

1  16:24:43| 

TOBE 

Scenario 

(default) 

Instances 

rioo 

Activity 

Performer 

Occurs 

Waiting  Time 
(Time) 

Time  To  Complete 
(Time) 

Total  Time 
(Time) 

Approves  81  mm  mortar 

FSC 

16 

0:00:00 

0:08:00 

0:08:00 

Approves  Arty 

FSC 

55 

0:00:00 

0:55:00 

0:55:00 

Approves  CAS 

FSC 

10 

0:00:00 

0:20:00 

0:20:00 

Approves  NGF 

FSC 

1 

0:00:00 

0:02:00 

0:02:00 

Assigns  organic  fires 

Any  member  of  FiSTLeader 

10 

0:00:51 

0:10:00 

0:10:51 

Computes  firing  data 

All  member(s)  of  Artillery  Battery 

55 

0:02:10 

0:09:10 

0:11:20 

FSCC  processes  CFF 

FSC 

83 

0:00:29 

0:41:30 

0:41:59 

Observer  gathers  target  da 

Observer 

95 

0:00:24 

0:47:30 

0:47:54 

Process  CFF 

Any  member  of  FiSTLeader 

95 

0:04:08 

0:47:30 

0:51:38 

Receives  Arty  CFF 

All  member(s)  of  Artillery  Battery 

55 

0:00:21 

1:50:00 

1:50:21 

Records  MTO 

Observer 

55 

0:02:09 

0:00:55 

0:03:04 

Requests  81mm  mortars 

Any  member  of  FiSTLeader 

19 

0:00:00 

0:38:00 

0:38:00 

Requests  Arty 

Any  member  of  FiSTLeader 

48 

0:00:05 

1:36:00 

1:36:05 

Requests  CAS 

Any  member  of  FiSTLeader 

15 

0:00:00 

0:30:00 

0:30:00 

Requests  NGF 

Any  member  of  FiSTLeader 

1 

0:00:00 

0:02:00 

0:02:00 

Requests  battalion  fires 

Any  member  of  FiSTLeader 

83 

0:00:30 

4:09:00 

4:09:30 

Resource 

Unit 

Cost/Unit 

Threshold 

Usage 

Cost 

Observer 

Hour 

12 

0 

0 

0 

FSC 

Hour 

31 

0 

2 

62 

Any  member  of  FiSTLeader 

Hour 

20 

0 

7 

140 

All  member(s)  of  Artillery  B 

Hour 

14.25 

0 

218 

3106.5 

Performers  Queue  Length  and  Utilization 

Name 

Average 

Min 

Max 

Utilized(%) 

Idle(%) 

Observer 

0.01 

0 

1 

11.08 

88.92 

FSC 

0 

0 

1 

28.95 

71.05 

Any  member  of  FiSTLeader 

0.01 

0 

1 

54.07 

45.93 

All  member(s)  of  Artillery  B 

0.01 

0 

1 

27.27 

72.73 

Bottlenecks 

_ 

1  1  1 

Process 

Activity 

Performer 

Avg  Queue 
Length 

Min  Queue  Length 

Max  Queue 
Length 

TOBE 

Assigns  organic  fires 

Any  member  of  FiSTLeader 

0 

0 

1 

TOBE 

Computes  firing  data 

All  member(s)  of  Artillery  Battery 

0 

0 

1 

TOBE 

FSCC  processes  CFF 

FSC 

0 

0 

1 

TOBE 

Observer  gathers  target  data 

Observer 

0 

0 

1 

TOBE 

Process  CFF 

Any  member  of  FiSTLeader 

0.01 

0 

1 

TOBE 

Receives  Arty  CFF 

All  member(s)  of  Artillery  Battery 

0 

0 

1 

TOBE 

Records  MTO 

Observer 

0 

0 

1 

TOBE 

Requests  Arty 

Any  member  of  FiSTLeader 

0 

0 

1 

TOBE 

Requests  battalion  fires 

Any  member  of  FiSTLeader 

0 

0 

1 

Note: 

Red-marked  Waiting  Time  values  indicates  "Activity  has  waiting  time" 

Red-marked  Usage  values  indicates  "Usage  crossed  threshold" 
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APPENDIX  H 


MOS  0861,  FIRE  SUPPORT  MAN  Mission  Essential  Tasks  List 

DUTY  AREA  01-MAP  READING  AND  M2  COMPASS 

1.  TASK:  0861.01.01  (CORE)  DECLINATE  AN  M2  COMPASS  USING  THE  FIELD 
EXPEDIENT  METHOD 

2.  TASK:  0861.01.02  (CORE)  ORIENT  A  MAP  USING  A  DECLINATED  M2  COMPASS 

3.  TASK:  0861.01.03  (CORE)  LOCATE  YOUR  POSITION  DURING  A  TERRAIN  WALK 

4.  TASK:  0861.01.04  (CORE)  NAVIGATE  FROM  ONE  POINT  ON  THE  GROUND  TO 

ANOTHER  POINT,  MOUNTED 

5.  TASK:  0861.01.05  (CORE)  LOCATE  POSITIONS  IN  A  MOBILE  ENVIRONMENT 

6.  TASK:  0861.01.06  (CORE)  DETERMINE  LOCATION  WITH  THE  AN/GVS-5  LASER 

RANGE  FINDER 

7.  TASK:  0861.01.07  (CORE)  DETERMINE  LOCATION  WITH  THE  AN/PAQ-3  MODULAR 
UNIVERSAL  LASER  EQUIPMENT  (MULE)  USING  TWO  KNOWN  POINTS 

8.  TASK:  0861.01.08  (CORE  PLUS)  DETERMINE  LOCATION  WITH  THE  AN/PAQ-3 
MODULAR  UNIVERSAL  LASER  EQUIPMENT  (MULE)  USING  ONE  KNOWN  POINT  AND  A 
BURST 

9.  TASK:  0861.01.09  (CORE  PLUS)  DETERMINE  LOCATION  WITH  THE  AN/PAQ-3 
MODULAR  UNIVERSAL  LASER  EQUIPMENT  (MULE)  USING  TWO  BURSTS 

10.  TASK:  0861.01.10  (CORE)  DETERMINE  LOCATION  WITH  THE  AN/PAQ-3  MODULAR 
UNIVERSAL  LASER  EQUIPMENT  (MULE)  USING  SELF-LOCATION  PROCEDURE 

11.  TASK:  0861.01.11  (CORE)  LOCATE  POSITION  ON  A  MAP  OR  GROUND  BY 
RESECTION 

12.  TASK:  0861.01.12  (CORE)  DETERMINE  THE  ELEVATION  OF  A  POINT  ON  THE 
GROUND  USING  A  MAP 

13.  TASK:  0861.01.13  (CORE)  DETERMINE  A  POSITION  WITH  THE  AN/PSN-11  PLGR 
IN  THE  AVERAGING  MODE 

14.  TASK:  0861.01.14  (CORE)  PERFORM  NAVIGATION  PROCEDURES  WITH  THE  AN/PSN- 
11  PLGR 

15.  TASK:  0861.01.15  (CORE  PLUS)  CONDUCT  BATTLEFIELD  REPORTING 
DUTY  AREA  02-COMMUNICATIONS 

16.  TASK:  0861.02.01  (CORE)  ESTABLISH/ENTER  AND  LEAVE  A  RADIO  TELEPHONE 
NET 

17.  TASK:  0861.02.02  (CORE  PLUS)  ENCODE/DECODE/AUTHENTICATE  USING  THE 
NUMERAL  CIPHER/AUTHENTICATION  SYSTEM 

18.  TASK:  0861.02.04  (CORE)  SEND  AND  RECEIVE  RADIO  TRANSMISSIONS  USING 
PROPER  RADIO  TELEPHONE  PROCEDURES 
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19.  TASK:  0861.02.05  (CORE  PLUS)  TRANSMIT  A  MESSAGE  UTILIZING  NATO  FORMAT 

20.  TASK:  0861.02.06  (CORE  PLUS)  DRAFT  A  MESSAGE  USING  NATO  FORMAT 

21.  TASK:  0861.02.07  (CORE)  OPERATE  AN  FM  RADIO  SET  AN/PRC-119 

22.  TASK:  0861.02.08  (CORE  PLUS)  INSTALL  AN/VRC-88  RADIO  SET 

23.  TASK:  0861.02.09  (CORE  PLUS)  OPERATE  A  AN/VRC-88  RADIO  SET 

24.  TASK:  0861.02.10  (CORE  PLUS)  INSTALL  AN/MRC-145  RADIO  SET 

25.  TASK:  0861.02.11  (CORE  PLUS)  OPERATE  AN  AN/MRC-145  RADIO  SET 

26.  TASK:  0861.02.15  (CORE)  OPERATE  AN  AN/PRC-104  RADIO  SET 

27.  TASK:  0861.02.16  (CORE  PLUS)  INSTALL  AN/MRC-138  RADIO  SET 

28.  TASK:  0861.02.17  (CORE  PLUS)  OPERATE  AN  AN/MRC-138  RADIO  SET 

29.  TASK:  0861.02.18  (CORE  PLUS)  PREPARE/OPERATE  TSEC/KY-99  COMMUNICATIONS 
SECURITY  EQUIPMENT  WITH  AN  AM  RADIO  SET 

30.  TASK:  0861.02.19  (CORE)  ERECT  OE-254  ANTENNA 

31.  TASK:  0861.02.20  (CORE)  INSTALL  AND  OPERATE  RADIO  SET  CONTROL  GROUP 
AN/GRA-3 9  AND/OR  AN/ PRC- 11 9C  FOR  REMOTE  OPERATION 

32.  TASK:  0861.02.21  (CORE  PLUS)  OPERATE  AND  MAINTAIN  A  FIELD  PHONE 

33.  TASK:  0861.02.22  (CORE  PLUS)  EMPLOY  THE  AN/PPN-19  TRANSPONDER  SET 
(RADAR  BEACON) 

34.  TASK:  0861.02.23  (CORE)  MAINTAIN  COMMUNICATIONS  EQUIPMENT 

35.  TASK:  0861.02.24  (CORE  PLUS)  IDENTIFY  ELECTRONIC  COUNTERMEASURES  (ECM) 
AND  IMPLEMENT  ELECTRONIC  COUNTER-COUNTERMEASURES  (ECCM) 

36.  TASK:  0861.02.25  (CORE  PLUS)  PREPARE/SUBMIT  OPERATOR'S  MEACONING, 
INTRUSION,  JAMMING,  AND  INTERFERENCE  (MIJI)  REPORT 

DUTY  AREA  03-QBSERVED  FIRE  PROCEDURES 

37.  TASK:  0861.03.01  (CORE)  SELECT  AN  OBSERVATION  POST  AND  PREPARE  TO  USE 


IT 

38.  TASK:  0861.03.02  (CORE)  PREPARE  AN  OBSERVATION  POST  FOR  USE  WHILE 


AN /PAG 

-3  MODULAR 

UNIVERSAL  LASER 

EQUIPMENT 

(MULE)  EQUIPPED 

39. 

TASK: 

0861.03.03 

(CORE) 

PLACE  THE 

OBSERVED 

FIRE  (OF)  FAN  ON  A 

MAP 

40. 

TASK: 

0861.03.04 

(CORE) 

DETERMINE 

DIRECTION 

TO  TWO  TARGETS 

41  . 

TASK: 

0861.03.05 

(CORE) 

CONSTRUCT 

A  TERRAIN 

SKETCH 

42. 

TASK: 

0861.03.06 

(CORE 

PLUS)  PREPARE  A  VISIBILITY  DIAGRAM 

43. 

TASK: 

0861.03.07 

(CORE) 

LOCATE  A 

TARGET  BY 

GRID  COORDINATES 

44  . 

TASK: 

0861.03.08 

(CORE) 

LOCATE  A 

TARGET  BY 

POLAR  PLOT 

45. 

TASK: 

0861.03.09 

(CORE) 

LOCATE  A 

TARGET  BY 

SHIFT  FROM  A  KNOWN 

POINT 
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46.  TASK:  0861.03.10  (CORE)  MEASURE  ANGULAR  DEVIATION  WITH  YOUR  HAND 

47.  TASK:  0861.03.11  (CORE)  CONDUCT  AN  ADJUST  FIRE  MISSION 

48.  TASK:  0861.03.12  (CORE)  OPERATE  THE  AN/GVS-5  LASER  RANGE  FINDER 

49.  TASK:  0861.03.13  (CORE)  REQUEST  AND  ADJUST  FIRE  WITH  THE  AN/GVS-5 

LASER  RANGE  FINDER 

50.  TASK:  0861.03.14  (CORE)  PERFORM  PREVENTIVE  MAINTENANCE  CHECKS  AND 
SERVICES  ON  AN/GVS-5  LASER  RANGE  FINDER 

51.  TASK:  0861.03.15  (CORE)  PREPARE  THE  AN/PAQ-3  MODULAR  UNIVERSAL  LASER 
EQUIPMENT  (MULE)  FOR  OPERATION 

52.  TASK:  0861.03.16  (CORE)  CONDUCT  A  FIRE  MISSION  WITH  THE  AN/PAQ-3 
MODULAR  UNIVERSAL  LASER  EQUIPMENT  (MULE) 

53.  TASK:  0861.03.17  (CORE  PLUS)  CONDUCT  A  SUPPRESSION  MISSION  ON  A 
PLANNED  TARGET 

54.  TASK:  0861.03.18  (CORE)  CONDUCT  AN  IMMEDIATE  SUPPRESSION  MISSION 

55.  TASK:  0861.03.19  (CORE)  CONDUCT  A  FIRE  FOR  EFFECT  (FFE)  MISSION 

56.  TASK:  0861.03.20  (CORE)  CONDUCT  AN  ILLUMINATION  MISSION 

57.  TASK:  0861.03.21  (CORE)  CONDUCT  A  COORDINATED  ILLUMINATION  MISSION 

58.  TASK:  0861.03.22  (CORE  PLUS)  CONDUCT  A  FASCAM  MISSION 

59.  TASK:  0861.03.23  (CORE  PLUS)  CONDUCT  A  DPICM  MISSION 

60.  TASK:  0861.03.24  (CORE)  CONDUCT  A  DANGER  CLOSE  FIRE  MISSION 

61.  TASK:  0861.03.26  (CORE  PLUS)  CONDUCT  TWO  FIRE  MISSIONS  SIMULTANEOUSLY 

62.  TASK:  0861.03.27  (CORE  PLUS)  ADJUST  FINAL  PROTECTIVE  FIRES 

63.  TASK:  0861.03.28  (CORE)  CONDUCT  AN  IMMEDIATE  SMOKE  MISSION 

64.  TASK:  0861.03.29  (CORE)  CONDUCT  A  QUICK  SMOKE  MISSION 

65.  TASK:  0861.03.30  (CORE  PLUS)  CONDUCT  A  DESTRUCTION  MISSION 

66.  TASK:  0861.03.31  (CORE)  CONDUCT  A  MISSION  ON  A  MOVING  TARGET 

67.  TASK:  0861.03.32  (CORE)  SELECT  AND  LOCATE  REGISTRATION  POINTS 

68.  TASK:  0861.03.33  (CORE)  CONDUCT  A  PRECISION  REGISTRATION,  QUICK  AND 
TIME 

69.  TASK:  0861.03.34  (CORE)  CONDUCT  A  HIGH-BURST  OR  MEAN-POINT-OF-IMPACT 
(MPI )  REGISTRATION 

70.  TASK:  0861.03.35  (CORE)  CONDUCT  AN  ABBREVIATED  REGISTRATION 

71.  TASK:  0861.03.36  (CORE  PLUS)  CONDUCT  A  MEAN-POINT-OF-IMPACT  (MPI) 
REGISTRATION  WITH  AN  AN/PAQ-3  MODULAR  UNIVERSAL  LASER  EQUIPMENT  (MULE) 

TASK:  0861.03.37  (CORE  PLUS)  CONDUCT  EMERGENCY  OBSERVER  PROCEDURES 
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72. 


73.  TASK:  0861.03.38  (CORE  PLUS)  CONDUCT  A  MORTAR  PRECISION  REGISTRATION 

74.  TASK:  0861.03.40  (CORE  PLUS)  CONDUCT  FIRE  MISSION  ON  IRREGULARLY 

SHAPED  TARGETS 

75.  TASK:  0861.03.41  (CORE  PLUS)  CONDUCT  A  COPPERHEAD  MISSION 

76.  TASK:  0861.03.42  (CORE  PLUS)  DIRECT  A  CLOSE  AIR  SUPPORT  (CAS)  STRIKE 

77.  TASK:  0861.03.43  (CORE)  CONDUCT  AN  ARTILLERY  SUPPRESSION  OF  ENEMY  AIR 
DEFENSE  (SEAD) 

78.  TASK:  0861.03.44  (CORE)  CONDUCT  A  NAVAL  SURFACE  FIRE  SUPPORT  (NSFS) 
MISSION 

79.  TASK:  0861.03.45  (CORE)  CONDUCT  A  NAVAL  SURFACE  FIRE  SUPPORT  (NSFS) 
SUPPRESSION  OF  ENEMY  AIR  DEFENSE  (SEAD)  MISSION 

80.  TASK:  0861.03.46  (CORE)  CONDUCT  A  HIGH  ANGLE  FIRE  MISSION  WITH  NAVAL 
SURFACE  FIRE  SUPPORT  (NSFS) 

81.  TASK:  0861.03.47  (CORE)  CONDUCT  A  DANGER  CLOSE  FIRE  MISSION  WITH  NAVAL 
SURFACE  FIRE  SUPPORT  (NSFS) 

82.  TASK:  0861.03.48  (CORE)  REFIRE  A  RECORDED  TARGET  WITH  NAVAL  SURFACE 
FIRE  SUPPORT  (NSFS) 

83.  TASK:  0861.03.49  (CORE)  CONDUCT  AN  ILLUMINATION  MISSION  WITH  NAVAL 
SURFACE  FIRE  SUPPORT  (NSFS) 

84.  TASK:  0861.03.50  (CORE)  CONDUCT  A  FRESH  TARGET  SHIFT  MISSION  WITH 
NAVAL  SURFACE  FIRE  SUPPORT  (NSFS) 

85.  TASK:  0861.03.51  (CORE)  CONDUCT  SIMULTANEOUS  MISSIONS  WITH  NAVAL 
SURFACE  FIRE  SUPPORT  (NSFS) 

86.  TASK:  0861.03.52  (CORE)  CONDUCT  A  NEW  TARGET  SHIFT  MISSION  WITH  NAVAL 
SURFACE  FIRE  SUPPORT  (NSFS) 

87.  TASK:  0861.03.53  (CORE)  CONDUCT  A  NAVAL  GUNFIRE  (NGF)  COORDINATED 
ILLUMINATION  MISSION 

DUTY  AREA  04  -  FIRE  SUPPORT  PLANNING  AND  COORDINATION 

88.  TASK:  0861.04.04  (CORE  PLUS)  PREPARE/SUBMIT  A  LIST  OF  TARGETS 

89.  TASK:  0861.04.27  (CORE  PLUS)  INTEGRATE  COMPANY  ORGANIC  INDIRECT  FIRE 
WEAPONS  INTO  FIRE  PLANS 

DUTY  AREA  05-CQUNTERFIRE 

90.  TASK:  0861.05.01  (CORE  PLUS)  PERFORM  CRATER  ANALYSIS  FOR  LOW- ANGLE 
CRATERS 

91.  TASK:  0861.05.02  (CORE  PLUS)  PERFORM  CRATER  ANALYSIS  FOR  LOW-ANGLE 
FUZE  DELAY  CRATERS 

92.  TASK:  0861.05.03  (CORE  PLUS)  PERFORM  CRATER  ANALYSIS  FOR  HIGH-ANGLE 
CRATERS 

93.  TASK:  0861.05.04  (CORE  PLUS)  PERFORM  SHELL  FRAGMENT  ANALYSIS 
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94.  TASK:  0861.05.05  (CORE  PLUS)  PREPARE/SUBMIT  STANDARD  SHELLING, 
MORTARING,  AND  BOMBING  REPORT 

DUTY  AREA  07-QBSERVER  DIGITAL  TERMINAL  (OPT) 

95.  TASK:  0861.07.01  (CORE)  PREPARE  THE  OBSERVER  DIGITAL  TERMINAL  (ODT) 

FOR  OPERATION 

96.  TASK:  0861.07.02  (CORE)  ESTABLISH  COMMUNICATIONS  PARAMETERS  WITH  THE 
OBSERVER  DIGITAL  TERMINAL  (ODT) 

97.  TASK:  0861.07.03  (CORE)  DETERMINE  OBSERVER  LOCATION  WITH  THE  OBSERVER 
DIGITAL  TERMINAL  (ODT) 

98.  TASK:  0861.07.04  (CORE)  REPORT  OBSERVER  LOCATION  WITH  THE  OBSERVER 
DIGITAL  TERMINAL  (ODT) 

99.  TASK:  0861.07.05  (CORE)  PROCESS  AN  AREA  FIRE  MISSION  WITH  THE  OBSERVER 
DIGITAL  TERMINAL  (ODT) 

100.  TASK:  0861.07.06  (CORE)  PROCESS  SPECIAL  FIRE  MISSIONS  WITH  THE 
OBSERVER  DIGITAL  TERMINAL  (ODT) 

101.  TASK:  0861.07.07  (CORE)  CONDUCT  A  PRECISION  REGISTRATION  WITH  THE 
OBSERVER  DIGITAL  TERMINAL  (ODT) 

102.  TASK:  0861.07.08  (CORE)  CONDUCT  A  HIGH-BURST  (HB)  OR  MEAN -POINT -OF- 
IMPACT  (MPI )  REGISTRATION  WITH  THE  OBSERVER  DIGITAL  TERMINAL  (ODT) 

103.  TASK:  0861.07.09  (CORE  PLUS)  REPORT  ENEMY  ACTIVITY  BY  THE  USE  OF  THE 
ARTILLERY  TARGET  INTELLIGENCE  (ATI)  MESSAGES  WITH  THE  OBSERVER  DIGITAL 
TERMINAL  (ODT) 

104.  TASK:  0861.07.10  (CORE  PLUS)  TRANSMIT  A  TARGET  FOR  INCLUSION  IN  A  LIST 
OF  TARGETS  WITH  THE  OBSERVER  DIGITAL  TERMINAL  (ODT) 

105.  TASK:  0861.07.11  (CORE  PLUS)  REPORT  THE  FORWARD  LINE  OF  TROOPS  (FLOT) 
MESSAGE  WITH  THE  OBSERVER  DIGITAL  TERMINAL  (ODT) 

106.  TASK:  0861.07.12  (CORE  PLUS)  INPUT  A  TARGET  IN  THE  KNOWN  POINT  FILE 
WITH  THE  OBSERVER  DIGITAL  TERMINAL  (ODT) 

107.  TASK:  0861.07.13  (CORE  PLUS)  VERIFY  OBSERVER  DIGITAL  TERMINAL  (ODT) 
INITIALIZATION 
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Met  Support  is  based  on  the  foilwing  ordinal  scale  Tota  1  %  — 

0  =  not  at  all,  1  =  minimally,  2  =  mostly,  3  =  fully 
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